Re: [Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt
On Jan 31, 2018, at 09:28, Jan Jancar wrote: > 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. Yep; configuration options are read-only through REST because they are specified in the mailman.cfg file. You wouldn’t want to (and probably even can’t) allow REST clients to change things that aren’t kept in the database. On Jan 31, 2018, at 15:03, holger wrote: > sounds good. Is it also possible to hook into the standard mm3 configuration, > for adding a per-list configuration item that can then be processed by > plugin code? Per-list configurations are maintained in the database, configuration files (e.g. mailman.cfg) configure site-wide static settings. That’s because lists are dynamic; they can be created, deleted, and modified. But your plugin should be able to create its own tables and cross reference the mailing list tables (via the SQLAlchemy ORM). Static configurations can be added to a [plugins.autocrypt] section, or better a separate autocrypt.cfg file, much like the way we separate out the postfix.cfg settings. Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt
Hi Jan, On Wed, Jan 31, 2018 at 19:00 +0100, Jan Jancar wrote: > >> 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. Good to know! I added the links to the muacrypt issue i linked above. dkg and vincent (from k-9 mail) tell me write support of partial length header is not needed for e-mails, so that's good because i'd like muacrypt, my in-progress autocrypt implementation, to work with pgpy sometime (https://github.com/hpk42/muacrypt/issues/32 ) > >>> - 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. sounds good. Is it also possible to hook into the standard mm3 configuration, for adding a per-list configuration item that can then be processed by plugin code? holger signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt
>> 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. >> >> [mailman-pgp]: https://gitlab.com/J08nY/mailman-pgp >> [mailman-rest-events]: https://gitlab.com/J08nY/mailman-rest-events >> [PGPy]: https://github.com/SecurityInnovation/PGPy > > thanks a bunch for your feedback and links. > > holger > Glad that I could help! [django-pgpmailman]: https://gitlab.com/J08nY/django-pgpmailman Cheers, -- Jan __ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ # signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt
Hi Jan, On Wed, Jan 31, 2018 at 15:28 +0100, Jan Jancar wrote: > Hi all! > > On 01/25/2018 12:21 PM, holger krekel wrote: > > Indeed, i guess a plugin should get us >90% there. Here are my > > current technical considerations in a quick list: > > > > - Autocrypt L1 specifies how to generate an Autocrypt key, transfer and > > parse public keys and settings through headers of regular e-mails. > > > > - Mailman is to create and maintain a per-list Autocrypt account > > (managed through "muacrypt") which keeps track of > > subscriber's encryption settings by parsing incoming mail messages. > > muacrypt in turn uses "gpg" or "gpg2" and would maintain > > keyring/account data on a per-list basis. muacrypt also implements > > mime-encryption and decryption and needs to intercept incoming/outgoing > > mails. Can a plugin modify outgoing messages on a per-recipient basis? > > Yes a plugin can do that, although it has to go through some hoops as > when I was making the delivery part of the plugin support I didn't want > to change Mailman's delivery mechanisms too much, which means a plugin > doing this will have some code duplication/boilerplate. As there are > only 2 plugins currently([mailman-pgp] and [mailman-rest-events]), I > think the plugin API could still evolve. sounds good! > 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) > > - 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?) > > - 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. > > [mailman-pgp]: https://gitlab.com/J08nY/mailman-pgp > [mailman-rest-events]: https://gitlab.com/J08nY/mailman-rest-events > [PGPy]: https://github.com/SecurityInnovation/PGPy thanks a bunch for your feedback and links. holger signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt
Hi all! On 01/25/2018 12:21 PM, holger krekel wrote: > Indeed, i guess a plugin should get us >90% there. Here are my > current technical considerations in a quick list: > > - Autocrypt L1 specifies how to generate an Autocrypt key, transfer and > parse public keys and settings through headers of regular e-mails. > > - Mailman is to create and maintain a per-list Autocrypt account > (managed through "muacrypt") which keeps track of > subscriber's encryption settings by parsing incoming mail messages. > muacrypt in turn uses "gpg" or "gpg2" and would maintain > keyring/account data on a per-list basis. muacrypt also implements > mime-encryption and decryption and needs to intercept incoming/outgoing > mails. Can a plugin modify outgoing messages on a per-recipient basis? Yes a plugin can do that, although it has to go through some hoops as when I was making the delivery part of the plugin support I didn't want to change Mailman's delivery mechanisms too much, which means a plugin doing this will have some code duplication/boilerplate. As there are only 2 plugins currently([mailman-pgp] and [mailman-rest-events]), I think the plugin API could still evolve. If you would like to use a Python OpenPGP implementation you could look at [PGPy] and how I used it in mailman-pgp. > > - 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. > > - 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. [mailman-pgp]: https://gitlab.com/J08nY/mailman-pgp [mailman-rest-events]: https://gitlab.com/J08nY/mailman-rest-events [PGPy]: https://github.com/SecurityInnovation/PGPy Cheers, -- Jan __ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ # signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
