[Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt

[Barry Warsaw]

Hi Holger.  Very cool initiative.  I just skimmed the specs for now, but I do like how it takes an opportunistic approach to key management, in order to simplify the UX and increase adoption.

> On Jan 21, 2018, at 00:47, holger krekel <holger at merlinux.eu> wrote:
> 
> maybe some of you know me for my works on pypy, tox or pytest but
> this mail will be about something else …

Indeed.  If autocrypt becomes even a fraction as amazing, joyful to use, and essential to our toolkits as those others that you work on, it will undoubtedly succeed.

> In the last year i co-instigated a new opportunistic mail encryption
> effort called Autocrypt (https://autocrypt.org). With Autocrypt Level 1,
> mail clients (e.g. enigmail, K-9 mail, Delta.chat, ...) send and parse
> public keys in "Autocrypt" e-mail headers and offer single-click
> encryption.  Releases are upcoming in spring 2018, we have been
> doing fun and well-received user-testing sessions already
> with in-development versions.

Have there been any talks about creating plugins for commercial MUAs like Mail.app, Postbox, and Outlook?  Do you have plans for webmail clients like Gmail or Outlook?

> In 2018, I'd like to tackle basic integration of Mailman and Autocrypt,
> to achieve opportunistically encrypted mailing lists.  The main idea is to
> grow a mailman mode/plugin to:
> 
> 1) have mailman lists maintain a public pgp identity that
>   is added through Autocrypt headers to outgoing mails.
> 
> 2) have mailman keep track of "incoming" autocrypt keys
>   and decrypt incoming mails if they are encrypted.
> 
> 3) encrypt to those subscribers where we have a proper Autocrypt key
> 
> Code wise, i'd like to tackle this based on the the new and evolving
> (and quite unpublic so far) "muacrypt" project:
> https://muacrypt.readthedocs.io
> 
>> From looking at archives and the GSOC idea page i see there were related
> efforts and ideas.  Are there pointers to draft implementations that
> are still somewhat up to date (with mm3)?

I’m not really sure what the state of those previous efforts are, i.e. whether they’d be applicable to the current code base without a serious rebase.  ISTM that at least some of the changes in general would still be applicable, e.g. model changes to manage keys.

> Also, i am considering to submit a project proposal for the
> Mozilla Mission Partners program which would include a few more
> things ... OnionMX routing for postfix, and documentation on
> how to setup a best-practise MM3 mail instance, and maybe organizing
> a sprint around the mentioned topics.

Cool.  I think for best-practices in standing up an instance, you should definitely look at Abhilash’s docker images.  A sprint would be fun for sure.  Are you thinking Pycon US 2018 or elsewhere?

> collaboration welcome'ly yours,
> 
> holger
> 
> P.S.: i had discussed mm-encryption with Barry 2-3 years ago
> and feel now, with Autocrypt getting out the door, it's all
> becoming more feasible.

Indeed; having a specification and library for many of the details would help quite a bit.

I’ll say this; there have been countless discussions on the mailing list about whether list traffic encryption really helps or not, how easy it would be to subvert, and other related topics.  I still think it’s an interesting and useful feature that will satisfy enough use cases to make it worth working on.  Then we have to ask whether this is of general utility to make it a built-in Mailman 3 feature.  That decision can certainly be deferred because you can probably get pretty far with the much better plugin support in Mailman 3.  I’m sure you could do a pretty good PoC as a plugin.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20180123/fbbeded6/attachment.sig>