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: pgpAzx89bKvW9.pgp
Description: PGP signature

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list

Reply via email to