Re: [XMas-Patch] Autocrypt support for Balsa

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 

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 

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 

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” 

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!


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!


Attachment: pgpSj9QKP6xfD.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]