Lacre - ongoing work

1. “Great renaming” — our fork is ours, let's reflect it with unifying the names used all over the code (see issue 81).

• Key lifecycle analysis and fixes. I've documented it with graphviz (see doc/key-lifecycle.gv.
• Database transactions.
• Another approach at encoding issues — there have been reports on broken encodings from Disroot users.

Python's email module provides a set of parsers for email messages, among them:

• BytesParser, which just consumes a bytes sequence and produces an EmailMessage, with all of its data and meta-data kept in memory;
• BytesHeaderParser, which only parses headers and doesn't provide features to access parts of a multi-part message.

The problem with the first approach is that if we choose to encrypt an EmailMessage, its contents is serialised by an appropriate email.generator implementation, instead of producing the original content. This is OK for payloads like text in pure ASCII or Unicode with Latin scripts, but things get tricky when we want to transfer non-Latin scripts (e.g. Japanese, Chinese, or any of the Cyrillic alphabets). (This is mostly caused by different Content-Transfer-Encoding being chosen by email.generator.)

BytesHeaderParser and its string counterpart let us only parse the headers and keep original message body in memory. The drawback is that we can't process multipart messages as sequences of MIME entities, which we need for one of the Lacre's modes of operation. (There are two: PGP/MIME with whole body encrypted and PGP/Inline with each part of multipart message encrypted separately.) We could use BytesHeaderParser with PGP/MIME only.