Hi Albrecht, On 12/23/2018 08:30:14 AM Sun, Albrecht Dreß wrote:
Hi all, first, I wish you all a Merry Christmas and a happy and peaceful new year! I hope you can enjoy this time with your friends and family! And if you have some spare time left, you might want to try a slightly larger patch, implementing Autocrypt support for Balsa. The patch is a little larger, and thus not included in this message, but can be loaded from <https://www.mynetcologne.de/~nc-dreszal/autocrypt-support.diff.bz2>. The purpose of the Autocrypt standard [1, 2] is to simplify and promote email encryption. On the sending side, this is achieved by adding the public key to a new message header (look at this message source…), including the sender's preference whether (s)he wants to receive encrypted messages. Based on this data, when a message is composed, an “educated guess” can be given whether or not the message may or should be encrypted. As you may know, Balsa since a long time recommends encryption if the public keys for all recipients are available in the key ring. My Autocrypt implementation extends this as (a) the public keys received in the Autocrypt headers are stored separately until they are actually needed (i.e. receiving messages with Autocrypt headers does *not* clutter the GPG key ring), and (b) evaluating the sender's preferences gives a better default for the recommendation. Autocrypt needs (of course) gpgme, and can be enabled by adding “--with-gpgme --enable-autocrypt” to the configure options. In order to track the received Autocrypt headers, I decided to use a trivial sqlite3 database which is stored in the ~/.balsa folder, i.e. the sqlite3 development libs are needed. With Autocrypt support, Balsa has the following new features: In the app and “File” menu, you will find a new option “Autocrypt Database” which opens a dialogue listing the collected Autocrypt data: mailbox, last message seen (with or without Autocrypt header), last message with Autocrypt header, and whether the user prefers encrypted messages (see sect. 1.3.1 of the standard). The database contains only senders for which at least one message with a valid Autocrypt header has been received. Initially, the list is of course empty. For every identity, a new “Security” option selects the requested Autocrypt mode (see sect. 1.3.2 of the standard). Whenever a new message is received (with the exception of automatically created or processed messages, currently multipart/report and text/calendar), iff any identity has Autocrypt enabled, the code looks for an Autocrypt header, evaluates it and stores the data in the database (see section 2.3 of the standard). If a received message is signed, and the key is not in the key ring, but in the Autocrypt database, a new button is added to the signature widget, offering to import the key from the Autocrypt database into the key ring (in addition to searching the key server). When sending a message, unless the user did deactivate Autocrypt support for the particular identity, select encryption or S/MIME, the Autocrypt database is checked to provide the recommendation for encryption (see sect. 2.4 of the standard). As to keep the compatibility with the current implementation, all users which are /not/ in the Autocrypt database, but have a valid key in the key ring, are treated as if they selected “prefer-encrypt=mutual” Autocrypt mode. Based upon the recommendation algorithm, either the “Send encrypted” or “Send unencrypted” buttons are pre-selected, and a warning is added to the message in the “discourage” case. If encryption is selected, the message will also be signed, and any missing public keys are imported from the Autocrypt database into the key ring (the dialogue warns about the latter). Note that the patch does neither implement the (optional) “key gossip” feature, nor any of the key setup features mentioned in the standard. The current implementation should be fully usable, though. I think I will add some features to the database viewer (remember window size, delete items, import key manually, …), but I don't have a schedule yet. As always, any comment will be highly appreciated! Cheers, Albrecht.
Thank you for the Christmas present! This is a big patch, so I've added an 'autocrypt' branch to the GitLab repo, for testing. It builds and runs, but I'm at the early stage of testing! Best for the New Year! Peter
Attachment:
pgpSj9QKP6xfD.pgp
Description: PGP signature