I'm one of those persons that always prefers a native application over some web stuff. Usually this comes from some things I want to have, may it be speed, offline capabilities or just hacking possibility. So as a long-time user and contributor of OpenStreetMap as well as an active firefighter I of course know about OpenFireMap. And of course I want a local version of it.

Well, the way to go is obvious for a KDE hacker, no? Right, using Marble, or better: using libmarble as explained in the KDE Techbase. So, what did I end up with? A small pure-Qt application that uses libmarble to display OpenStreetMap tiles, showing some custom placemarks. Those placemarks are collected directly from the OpenStreetMap (online) database using the Overpass API. Then a bit of brute-force XML parsing using QXmlStreamReader and then: pure awesomeness.

This currently is based on Qt4, therefore I use XML and parse it brute-force. Eventually I'll switch to a Qt5-based libmarble, and will use the builtin JSON-support of Qt5. And maybe one day I'll finally find an example on how to draw different graphics for different types of placemarks.

Of course, this is not entirely local. But the information about the extra placemarks can easily be saved locally and restored from there (in fact, that is what the first versions did before I starte using QNetworkAccessManager), and Marble caches the tiles so it will sort-of work even offline. And of course the source code is available for everyone to hack around with it: OSMhyd version 1.

For those that do not have the money or nationality to be included into the bullshit made in Germany network, or that simply say that this is, well, bullshit, there is the way to use DANE records. They have one disadvantage: they need DNSSEC to be really secure, and sadly my hoster Hetzner currently doesn't support that. But I thought that having them in place anyway can't hurt.

There are several ways to match a certificate by those records, e. g. you can assert that a specific certificate is used, or the root of your trust chain is a specific certificate. You can also publish the complete certificate or just a hash. Since I am a lazy folk I decided that I would publish the root of the certificate chain, i. e. the CAcert root certificate. This is slightly less secure as any certificate signed by CAcert.org for my domain name would be accepted, but the way CAcert works I would have to do that signing. On the other side this is one of the advantages, as I can change the keys and certs any time, as long as it is signed by CAcert the DANE records don't need to change. The other advantage is that the same record for every host and service I use, as all of them use CAcert.

Most howtos will end in "IN TLSA" records, which are for BIND nameservers. I run tinydns from the djbdns package, which uses a different format. So, how did I proceed?

I used the TLSA generator from huque.com, selected the desired options (usage: 2, selector: 1, signing type: 1) and pasted the CAcert.org root certificate. This resulted in

Now this needs to be converted to a tinydns record. Tinydns does not know about TLSA records, but you can drop any record type you want using the : line, you just need to know the record number. The record number of TLSA is 52 (see RfC 6698, section 7.1).

Now you need to convert the information from the record to binary. The first 3 bytes are easy, 2 1 1 translates to \002\001\001. For the rest I used a simple bash command, nothing especially fancy since I planned to run this only once anyway:

I used a TTL of 60 seconds first to be able to change this fastly if neccessary, but I didn't need that as I surprisingly got it right on the first try.

Then go to SSL-Tools.net, enter your server name, and look at the output. For CAcert signed stuff it shows a certificate error as it does not have CAcert.org root certificates in it's database, and it showed a DANE error for me because my DNS does not support DNSSEC.

I copied that record e.g. for my MX entry (i. e. _25._tcp.mx.sf-mail.de).

Time for another test, again using SSL-Tools.net

Two more tips, slightly related: if you are on an openSUSE system the CAcert certificates are not installed by default. But you don't have to do any magic by hand:

zypper in ca-certificates-cacert

And for those that want DNSSEC with tinydns: tinydnssec could be the way to go (haven't tested that yet).

Every once in a while I get bored and pick a random downstream platform and look on their CMake patches. The first time it was obviously Gentoo, because my toy machines run Gentoo. For reasons I don't remember anymore the next was Haiku. A bit strange, I never before (and basically never again) touched that OS. And at the moment it is OpenBSD.

I must say the findings are different. Gentoo still ships a lot of obscure old patches, that do e.g. platform fixes for things Gentoo doesn't really have anything to do with like AIX. I think most of them should be either send upstream or dropped, better sooner than later. Then they have a set of Python related patches because of the heavy Python usage in Gentoo. And of course the usual set of backports that are absolutely fine, especially as CMake 3.0 takes way longer than expected. I fought a long battle against some of the Python stuff because that actually broke stuff just to get it compliant with their thinking of how it should be, and finally gave them a clean version that does what they want (i.e. respect the global Python default version of the system) without breaking applications requesting a specific version. Meanwhile I get added to CMake bugs to give comments if patches are fine, so I file that as success.

Haiku had a bunch of platform fixups for their own stuff, because their API changed or whatever. I cleaned them up, submitted upstream what was sensible, and from what I know they should not need a single downstream patch once CMake 3.0 is released. One of the Haiku developers now comes into the CMake IRC channel every now and then to ask for comments or simply sends patches. Success, definitely.

OpenBSD is another beast. It is a bit like a mix of Gentoo and Haiku, having all sorts of arcane and obsolete stuff in it (i.e. things that are not needed at all because the code would work the same without their patches), as well as their platform stuff. One example is that Linux systems have their man pages in */share/man, while OpenBSD uses */man. Those stuff is currently sitting in the next branch, probably going to master soon if nothing unexpected shows up. Then there is the obsolete stuff, that can only be cleaned up by the OpenBSD folks themselves. I had the impression that the stuff that Gentoo shipped at least did make a change in behavior, some of the OpenBSD stuff can simply be discarded without anyone noticing. And then there is their platform specific stuff. OpenBSD does not want sonames in libraries, which is one feature that makes work on an ELF based platform much more comfortable. This will probably not go upstream anytime soon. But hopefully their huge patchset will shrink soon.