Tag Archives: Enigmail

Results from the inofficial Enigmail “Night of Code”

Yesterday, we had a small “Night of Code” in Hamburg. Basically, five hackers met up in the rooms of the CCC Hamburg and tried to improve Enigmail, the Thunderbird extension for PGP-encrypting Mails. It was a hell of a lot of fun, and we actually made quite a bit of progress on several improvements.

It all started with a discussion on the mailing list of the computer science department of the University of Hamburg. We had a lengthy discussion on what is wrong with Enigmail and PGP, and some of us decided to do something about it. Someone organized a room, called for a “Night of Code”, and a few people responded, me among them.

We started with a short introduction on the architecture of Enigmail and what the important files are. Afterwards, we discussed what needed improvements (the consensus being “basically everything about the UI”) and everyone chose one of the proposed improvements and started working.

I don’t want to spoil the surprise on what the others have been working (although all of it will come in pretty handy, once it is finished and hopefully merged into the main project), but I can say a bit about what I worked on.

So, one of the important things when using PGP is to manage your Web of Trust. This includes the signing of the keys of other people (after you validated that they are, in fact, the person they are saying they are). For that purpose, there are Key-signing parties. And one of the major annoyances about those parties is the distribution of freshly signed keys.

On Linux, there is a neat command line tool called caff. It takes any number of Key-IDs, downloads the public keys, signs each ID seperately and mails it (encrypted) to the provided eMail address. The problem is that caff is pretty annoying to set up, and only works on Linux.

The Feature I am working on is something along those lines. I added a new checkbox on sigining keys…

The second checkbox is new, in case you were wondering.
The second checkbox is new, in case you were wondering. And the keys are totally legit, I checked. 😉

If you select the checkbox and sign a key (and no error occurs during the signing process), a new Message composition window will open:

The new Message

It will contain some sort of preset text and have the signed public key attached.

Now, this is all working great already, but there are still some things to do:

  • Save the last decision on whether to mail the key or not (currently, due to some weird behaviour of the Enigmail preferences function that I still need to figure out, it is not saved)
  • Automatically set the mail to be encrypted and signed, regardless of the settings.
  • Perhaps encrypt the public key before attaching it, to make sure the recipient needs his private key to get the new signatures?
  • Perhaps choose the sending account based on the private key that was used to sign the public key?

Now, the experience to work on Enigmail has been interesting and somewhat cool, but not without its problems.

  • To say the documentation of Enigmail is bad would be misleading, as it implies that there actually is a documentation, which is not the case. Everything you want to use, you need to figure out yourself, possibly by using the addon with debug output active and seeing which functions are used in what order.
  • Thunderbird isn’t much better. Many of the important functions (adding an attachment!) had to be reverse engineered from other addons or from the very helpful thunderbird-stdlib-Project on GitHub, as the documentation has some pretty big holes in significant places.

If you are an Enigmail dev and reading this: Please provide at least some documentation on what is done where in the code, and what APIs can be used for new features. I know you probably understand the code, but it makes the entry barrier for new devs very high.

If you are a Thunderbird dev: See above. The current docs are not enough, and the function names are in parts weird enough to make it almost impossible to find out how to actually use them without checking the source files, which takes time and is extremely annoying.

All in all, I enjoyed my time hacking on Enigmail. But it could have been a lot more productive if there was some form of documentation one could use. As for the new feature: I will try to get it to work properly and then submit a patch to the devs, but I do not know how long that will take, as my time is currently pretty limited because of other things I need to take care of (my bachelors thesis among them).

As for the others: I don’t know when their features will be finished, but we already have a bunch of ideas on what to do next, and if we find the time, we’ll create some more new features. Some of our ideas have the potential to vastly increase usability, so I am very curious as to the reactions of the devs. Let’s hope for the best.