If you would like to use a Python OpenPGP implementation you could look at PGPy and how I used it in mailman-pgp.
It's under consideration here: https://github.com/hpk42/muacrypt/issues/32 Are your experiences with pgpy indicating it's compatible with enigmail and k9-mail? (see the questions on that issue)
PGPy is a quite complete OpenPGP(RFC4880) implementation, its support table shows that:
https://pgpy.readthedocs.io/en/latest/progress.html
The unsupported packets are very rarely used nowadays and are only really produced by very old PGP clients, afaik. PGPy also has a quite extensive test suite that works with gpg internally.
I suggest you look at PGPy issue tracker to see what it lacks currently, the most painful issue I think is the missing support for writing partial length packets. It can read them just well but not output them.
- No special interface is needed on the mailing list web page maybe except from enabling/disabling the plugin/support.
Plugin configuration is done through the Mailman configuration and those are read-only through the REST interface. However a plugin might supply it's own REST endpoints for example for per-list setup/configuration.
I guess read-only REST would allow for a command line interface for debugging or other low-level configuration wrt to autocrypt key status for peers. Can a plugin add per-list configuration options (enable/disable, maybe a choice between 2-3 policies?)
Yes definitely, the configuration will be handled completely inside the pkugin. I'm thinking along the lines of:
Expose a custom REST endpoint for per-list Autocrypt configuration, that can be read-write, however is only protected by one global REST user-password pair. That will be accessed by an Autocrypt Django app, similarly to how I implemented configuration for mailman-pgp in django-pgpmailman. That app can be then run alongside Postorius and HyperKitty which provide Mailman's configuration and archives. So this gives list admins a simple web UI for per-list Autocrypt configuration.
Provide a CLI command component which can manage the per-list Autocrypt configuration of the Mailman instance locally.
That should make per-list configuration of Autocrypt quite nice(I did mailman-pgp per-list config exactly this way). You can also read more on my blog, which contains my GSoC reports and goes into a bit more depth, https://neuromancer.sk/article/18 and other GSoC articles.
With the current Autocrypt specification, a mailman list will need to have the DMARC-mitigation "replace-from" action enabled to a) allow the list's public key to be added to outgoing mails in an Autocrypt compliant way b) send properly signed and encrypted mails to those subscribers which are Autocrypt-capable and have a "mutual" prefer-encrypt settings (see Autocrypt spec for details "prefer-encrypt"). If we get this to work nicely i think we can see about advancing the Autocrypt spec to support other ML modes (i.e. not replacing From).
For a mixed set of subscribers (some with and some without Autocrypt support) mailman will send out encrypted and unencrypted mails respectively. The status of the group might be added to a group's footer so that subscribers know about the group's security status (and get incentivized to upgrade their e-mail program).
Does that sound sensible? And achievable through a plugin, leaving the core (largely) untouched?
I definitely think so.
thanks a bunch for your feedback and links.
holger
Glad that I could help!
Cheers,
Jan
/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #