5 files changed, 305 insertions, 0 deletions
diff --git a/content/posts/2015-06-28-it_s-alive-again.md b/content/posts/2015-06-28-it_s-alive-again.md
new file mode 100644
index 0000000..ccc34a4
--- /dev/null
+++ b/content/posts/2015-06-28-it_s-alive-again.md
@@ -0,0 +1,75 @@
+$title "It's alive... again..."
+$tags webdev
+
+After putting it off for a few months, and a weekend of trying to make the
+perfect simple stylesheet, I finally got around to re-doing my website. It's
+now simpler, easier to read and actually has a blog.
+
+$pre
+
+Initially I was going to write my own static content generator in python using
+[Jinja2][jinja], pygments and docutils. I realise that doing this was going to
+be a giant pain and I didn't quite have the time to actually try to make one.
+I've heard about [Jekyll][jekyll] before and decided to investigate. I was
+hoping it was written in python but was instead written in ruby, however, in
+the end, this didn't matter.
+
+I was initially greeted by an _interesting_ layout and became worried that if I
+went any further I would be here for the rest of the day trying to wrangle the
+thing into submission.
+
+I started with the basics, I changed a few details in the config, this made
+some text change and remove some other text so I went about exploring. I knew
+Jekyll was using [Liquid][liquid] templates and having used Jinja before I knew what I
+was looking for.
+
+I quickly discovered that `/_layouts` stored a set of "base" templates which
+included a set of templates from `/_includes` to bring stuff together. This
+wasn't too bad.
+
+I then found `/css` or more importantly `/css/main.scss`. I've never seen an
+"scss" extension before but at first glance it looked a bit like CSS. At a
+second glance it looked like a css generator. I didn't really need this, the
+CSS for this website is in no way complex enough to warrant templating css, so
+I got to work modifying the existing `_layouts` and `_includes`, and simply
+copied in my usual css.
+
+Within about 10 minutes I had a working front page design but I noticed
+something annoying; the generated HTML had about 10 line breaks in the middle
+and generally looked like a mess. I realised that most of this space was
+because of Liquid's tokens leaving space. After moving all the tokens around in
+a way which meant that minimal breaks were introduced, I was left with
+something presentable.
+
+But this wasn't the end of the weirdness, the next problem was that for some
+reason, the indentation on the very first line of an imported template was
+always correct, but subsequent indentation was broken. (I was hoping that, like
+many text editors, Liquid might take the indent on the line where a block is
+being pasted and copy it for every line of the block, but on second thought,
+this might not be desirable for for example, `<pre>`). I had to fix this by
+indenting all but the first line correctly in every `/_includes` template and
+this managed to cover most of the cases.
+
+In the end, after pasting the syntax highlighting from
+`/_sass/_syntax-highlighting.scss` into my stylesheet and manually "generating"
+all the required entries. I was left with this very end result you see before
+you. As a final verdict, I really do think that Jekyll is quite awesome even
+though I've probably not used it in the most efficient fashion. All things
+considered, however, this only took about an hour.
+
+Now, bask in the glory of the syntax highlighting:
+
+~~~.c
+#include <stdio.h>
+
+int main(void)
+{
+	puts("Colours!!!");
+
+	return 0;
+}
+~~~
+
+[jekyll]: http://jekyllrb.com
+[jinja]:  http://jinja.pocoo.org/
+[liquid]: http://liquidmarkup.org/
diff --git a/content/posts/2015-08-16-mystery-ds-record.md b/content/posts/2015-08-16-mystery-ds-record.md
new file mode 100644
index 0000000..9757503
--- /dev/null
+++ b/content/posts/2015-08-16-mystery-ds-record.md
@@ -0,0 +1,79 @@
+$title "The mystery DS record"
+$tags DNS DNSSEC
+
+So after transferring my domain from transip.eu to namecheap.com for WHOIS
+privacy I realised that suddenly the Google public DNS servers were no longer
+able to resolve my domain. Very quickly, I realised that quite a few things
+seemed to rely on the Google public DNS services (and DNSSEC supporting
+resolvers). Fun ensued.
+
+$pre
+
+DNSSEC is a fancy extension to DNS which allows resolvers to cryptographically
+confirm, through the use of some public keys and signatures, that the records
+they are looking up are in fact the records they want and not the result of
+some MITM attack. This is explained well in multiple places, so I won't explain
+it here.
+
+I transferred my domain from transip.eu who provide DNSSEC (no way to publish
+DS records, everything is maintained in the background), but don't provide
+WHOIS privacy, to namecheap.com who do provide WHOIS privacy but don't provide
+DNSSEC. The DS record that transip.eu published to gtld-servers for their
+DNSSEC was left published after I transferred which initially, for someone who
+didn't know anything about DNSSEC, caused many confusing side effects.
+
+DS records have to be published in the parent zone, this means that it has to
+be done through your registrar. (Unless you have a lot of money and time and
+feel like bribing Verisign. If someone knows how to do this without bribery,
+tell me!). Upon contacting namecheap about the issue, the person I was talking
+to seemed confused about the issue. They seemed to think I was having issues
+with A and AAAA records and DNS propagation. They tried to inform me that I
+just had to wait. Of course, all the waiting in the world wouldn't get the DS
+records to disappear so after explaining the situation a bit better (I still
+didn't quite know much about it myself) I got them to contact their "upstream
+DNS provider."
+
+Finally, a weekend later, the DS record was gone and Google's DNS servers were
+serving my records again. Additionally, I switched over to using my own BIND
+name server so I could have full control over my DNS. This proved to be quite
+fun to set up. The second server is hosted by a good friend of mine and the
+third one by a friend of that friend. So far, other than me accidentally
+forgetting to enable named.service and rebooting my server to find that DNS
+wasn't working very well, I've had no problems.
+So after transferring my domain from transip.eu to namecheap.com for WHOIS
+privacy I realised that suddenly the Google public DNS servers were no longer
+able to resolve my domain. Very quickly, I realised that quite a few things
+seemed to rely on the Google public DNS services (and DNSSEC supporting
+resolvers). Fun ensued.
+
+DNSSEC is a fancy extension to DNS which allows resolvers to cryptographically
+confirm, through the use of some public keys and signatures, that the records
+they are looking up are in fact the records they want and not the result of
+some MITM attack. This is explained well in multiple places, so I won't explain
+it here.
+
+I transferred my domain from transip.eu who provide DNSSEC (no way to publish
+DS records, everything is maintained in the background), but don't provide
+WHOIS privacy, to namecheap.com who do provide WHOIS privacy but don't provide
+DNSSEC. The DS record that transip.eu published to gtld-servers for their
+DNSSEC was left published after I transferred which initially, for someone who
+didn't know anything about DNSSEC, caused many confusing side effects.
+
+DS records have to be published in the parent zone, this means that it has to
+be done through your registrar. (Unless you have a lot of money and time and
+feel like bribing Verisign. If someone knows how to do this without bribery,
+tell me!). Upon contacting namecheap about the issue, the person I was talking
+to seemed confused about the issue. They seemed to think I was having issues
+with A and AAAA records and DNS propagation. They tried to inform me that I
+just had to wait. Of course, all the waiting in the world wouldn't get the DS
+records to disappear so after explaining the situation a bit better (I still
+didn't quite know much about it myself) I got them to contact their "upstream
+DNS provider."
+
+Finally, a weekend later, the DS record was gone and Google's DNS servers were
+serving my records again. Additionally, I switched over to using my own BIND
+name server so I could have full control over my DNS. This proved to be quite
+fun to set up. The second server is hosted by a good friend of mine and the
+third one by a friend of that friend. So far, other than me accidentally
+forgetting to enable named.service and rebooting my server to find that DNS
+wasn't working very well, I've had no problems.
diff --git a/content/posts/2015-12-02-malloc-realloc-and-sizeof.md b/content/posts/2015-12-02-malloc-realloc-and-sizeof.md
new file mode 100644
index 0000000..ee3f508
--- /dev/null
+++ b/content/posts/2015-12-02-malloc-realloc-and-sizeof.md
@@ -0,0 +1,87 @@
+$title "malloc, realloc and sizeof"
+$tags information C
+
+I spend a lot of time in ##c hoping to provide useful information to people
+wishing to learn and understand C and almost every day I see malloc and realloc
+code which appears to be straight from a horror movie. I've had to say what I
+say in this post repeatedly to many people so I've decided that it's time to
+write it once and simply give people a link every time I wish to explain why
+such code is incorrect.
+
+$pre
+
+The code I'm describing is usually a combination of some or all of this:
+
+~~~ c
+struct foo *bar;
+
+bar = (struct foo *)malloc(sizeof(struct foo) * 10);
+
+bar = (struct foo *)realloc(bar, sizeof(struct foo) * 20);
+~~~
+
+There are multiple issues with this:
+
+ - Casting malloc can hide newbie mistakes such as forgetting to include
+   stdlib.h which can in turn cause strange issues down the line.
+ - Casting unnecessarily also gives you rather long lines, especially when you
+   have a rather complicated/long type (e.g. const struct foo * const *).
+ - You're having to type the same thing three times, when you could type it
+   once.
+ - If you screw up rewriting the same thing one of three times, you might end
+   up allocating the wrong amount of space and still end up with code which
+   runs, this can be dangerous down the line if some clever person finds a way
+   to exploit this.
+ - If you ever want to change the type of bar, you need to change it in 3
+   places, if you forget to change it in one of these, you end up with the same
+   issue described in the point above.
+ - Finally (regarding just the realloc line) if realloc fails, memory is leaked
+   since bar's original value is overwritten with NULL, realloc doesn't
+   automatically free the original pointer when it can't realloc.
+
+The easy solution is simply:
+
+~~~ c
+struct foo *bar, *tmpbar;
+
+bar = malloc(sizeof *bar * 10);
+
+tmpbar = realloc(bar, sizeof *tmpbar * 20);
+
+if (!tmpbar) {
+	free(bar);
+	/* error handling */
+} else {
+	bar = tmpbar;
+}
+~~~
+
+This solves all of the outlined problems.
+
+-----------------------
+
+Here's the answers to two common questions:
+
+**Q**: _The compiler has always complained (warned) when I tried to assign a
+pointer to one type to a pointer to another type. Would this not be the case
+here?_
+
+**A**: The C standard states (C11/C99 §6.3.2.3 and C11/C99 §6.5.16.1) roughly
+that a pointer to void can be assigned to a pointer to any type, and vice
+versa, freely without issuing a warning. This in turn means that the return
+value of malloc (and any other function returning void \*) will be converted
+without warning to the desired type without needing a cast.
+
+**Q**: _What's the deal with `sizeof *bar`? Don't functions need
+brackets?_
+
+
+**A**: The sizeof operator can be given an expression as an operand as well as
+the parenthesized name of a type. This means we can do `sizeof *bar`. Also,
+since sizeof is an _operator_ and **not** a function, it doesn't require
+parentheses when its operand is an expression, the C standard does however
+require that for types, the type name has to be parenthesized.  In the end, it's
+a style choice whether the parentheses are always there or not, but personally I
+think leaving them out is more consistent. (NB: The first example uses sizeof as
+such: `sizeof(type)`, personally I prefer leaving a space between `sizeof` and
+`(type)` as I would with most other operators.)
diff --git a/content/posts/2016-04-04-dnssec.md b/content/posts/2016-04-04-dnssec.md
new file mode 100644
index 0000000..13c1d60
--- /dev/null
+++ b/content/posts/2016-04-04-dnssec.md
@@ -0,0 +1,25 @@
+$title "DNSSEC"
+$tags information DNS DNSSEC
+
+As of today my domain finally supports DNSSEC. It was much simpler than I
+thought it would be. It seems namecheap now officially allows you to publish DS
+records in the parent zone of your domain (limited only to TLDs which support
+it). This is one of the last things that I wanted to set up on my server.
+
+$pre
+
+In the end, the process was made very simple by the existence of
+[this][cheatsheet] which details exactly how to set up DNSSEC on BIND 9.10 or
+higher.
+
+Currently the KSK is SHARSA256 1024 bits and the ZSK is SHARSA256 2048 bits, I
+am considering moving to using a 2048 bit KSK but I'm not sure if there will be
+much of a benefit.  I am using NSEC3 with a SHA-1 hash with the opt-out bit
+unset and 100 iterations.
+
+In any case, you can now rest assured that if your resolver uses DNSSEC
+(Google's resolvers will return a failure in case they find a DS record but the
+DNSSEC validation fails) you will be receiving signed and verifiable data.  Of
+course, I doubt many people care.
+
+[cheatsheet]: https://kb.isc.org/getAttach/122/AA-01311/DNSSEC-QR-B4.pdf
diff --git a/content/posts/2018-07-18-n900-fast-gps-fix.md b/content/posts/2018-07-18-n900-fast-gps-fix.md
new file mode 100644
index 0000000..33d3482
--- /dev/null
+++ b/content/posts/2018-07-18-n900-fast-gps-fix.md
@@ -0,0 +1,39 @@
+$title "N900 Fast GPS Fix"
+$tags N900 GPS
+
+If anyone is, like me, still using the N900, they may have noticed that
+acquiring an initial GPS fix can take minutes. The reason for this is that even
+in the latest CSSU, supl.nokia.com no longer works as a location server. The fix
+for this is actually relatively quick and easy and will make an initial GPS fix
+take seconds rather than minutes.
+
+$pre
+
+The exact details of what needs to be done can be found in the last few posts of
+[this][tmo-thread] Maemo forum thread. The problem is that supl.nokia.com no
+longer resolves to an IP address. However, this doesn't mean that the server
+behind supl.nokia.com is no longer running. Surprisingly, it still is.
+
+The long and short of it is this:
+
+1. Make sure you have the latest CSSU and a working N900 to begin with;
+2. Go [here][certman] and download `libmaemosec-certman0_0.2.10_armel.deb`,
+   `libmaemosec0_0.2.10_armel.deb`, `maemosec-certman-common-ca_0.2.10_all.deb`,
+   and `maemosec-certman-tools_0.2.10_armel.deb`;
+3. Install the above packages via the command line as root (you'll need gainroot)
+   by using `dpkg -i` (put all the files in their own directory and use `dpkg -i
+   *` to save time);
+4. Edit `/etc/hosts` and change `supl.nokia.com` to point to `52.200.182.188`;
+5. Check it all works by running `cmcli -T common-ca -v supl.nokia.com:7275` and
+   `cmcli -T location-proxy -v supl.nokia.com:7275`, both should say "Verified
+   OK.";
+6. If this doesn't work, try `stop location-proxy` and then
+   `start location-proxy` (as root) and go back to step 5.
+
+GPS fixes should happen very quickly now. If it's the year 2023 and this didn't
+work then good luck finding a new fix, hopefully you put the details on your
+blog too. Alternatively, feel free to contact me and I might still be using the
+N900 and might know how to help.
+
+[tmo-thread]: https://talk.maemo.org/showthread.php?t=90651
+[certman]:    http://maemo.merlin1991.at/cssu/community-devel/pool/free/m/maemo-security-certman