Hi Jan,

Congratulations and welcome to Mailman! Excerpts from Jan Jancar's message of May 10, 2017 5:07 pm:

Hi Mailman Developers.

I am sending this mail as my proposal of encrypted mailing lists for GNU Mailman got accepted and I will be working on it this summer.

Awesome!

Sorry about not contacting you earlier, I had some issues where my site and mail server were down. If any of you tried to reach me and failed in the last ~week you can try next time on my backup mail jancar.jj@gmail.com which should always work.

You can find the original (accepted) version of my proposal on: https://neuromancer.sk/static/mailman.pdf

# Status report so far into the Community bonding period:

• As it was proposed on this list a plugin-like implementation of encrypted mailing lists is really the only way to go forward here, as just pushing in what might end up being a rather niche feature into Mailman Core is not maintainable / wanted.

I feel like core already has the architecture(interfaces everywhere! :) that will make it pretty easy to write plugins. If you feel you need some changes in core to support your plugin better or plugins in general, I should be able to help you with that part.

• I started evaluating how much of my current proposal can be implemented without touching Mailman Core at all (as a plugin), what would require general changes and what might require specific changes (that means it needs a better solution).

• So far it seems most functionality of encrypted mailing lists can be easily implemented out-of-tree with only minor general changes to Mailman Core with the following exceptions that I'm currently solving:

  • Making all commands require a confirmation (as subscribe / unsubscribe has). This is necessary to stop replay attacks.

  • Subscription command needs to contain users public key, either as an argument or attachment or any other way the plugin might get it.

  • List key fingerprint and per-address/user key fingerprints need to be stored somehow, directly in the mailing list model would make the most sense, but that's very specific so the plugin should store this itself. Although that means data duplication.

  • Plugins don't seem to have a way to add features to the core REST API, so exposing key administration for Postorious that way is out.

  • Some questions that I had in my original proposal:
  • Is exposing key management through the REST api and Postorius a good idea at all? Those have very different level of access control, changing a key on a list requires a signed request + signed confirmation token whereas doing it in Postorius might only require a password.

True, but there is a lot of trust already there on the password for postorius. What if someone un-subscribes from the Postorius and then re-subscribes sending along a key not owned by the user?

I don't know if that did make any sense, because as I understand the subscription would be moderated and it would be up to List Admin to not allow keys he doesn't recognize to be subscribed? Is there anything else except the admin stopping some attacker from doing that?

+ A way of sharing the lists public key that makes the user trust it

the most.

I feel the key signed by the List Owner would be the best way to indentify the lists public key. Maybe mandate signing by the Site Owner and List Owner/List Owners?

# What I would like to definitely finish in the Community bonding period:

• Finish SMTPS/STARTTLS support for Mailman Core (really only needs tests now): https://gitlab.com/J08nY/mailman/tree/mta-smtps-starttls
• Establish real-time communication channels with mentors (text/voice?) and have a meeting to discuss the proposal.

I am available as maxking on IRC(#mailman). I am a little busy for next week and then we have Pycon, but I should be able to meet you anytime after Friday 26th. I am not very sure, but I will have some time on 17th too, I will let you know?

• Add proper objective milestones to the proposal.
• Change the proposal to reflect movement towards a more plugin-like implementation.

I hope this summer is fun for you!

thanks, Abhilash

-- thanks, Abhilash Raj

Hi all.

Currently still looking into what changes will be necessary in core in order to cleanly implement encrypted mailing lists as a plugin, so this is my second status report. I will start doing these pretty much weekly now, and definitely weekly/ more frequent when the coding period starts.

All of my reports (currently only this one) can be found on: https://neuromancer.sk/ https://neuromancer.sk/recent.atom

(https://neuromancer.sk/article/2)

Also pasting it here for clarity and replies:

## Plugin API enhancements in Core

To cleanly implement encrypted mailing lists as a plugin to Mailman Core I propose several general changes to the plugin api, to allow for cleaner integration of plugins, more flexibility and easier plugin deployment. First I present the current state of pluggability in Mailman core and then present the proposed changes.

### Current state

Relevant mailman-developers thread from GSoC 2015: https://mail.python.org/pipermail/mailman-developers/2015-March/024477.html

Example plugin: http://threebean.org/blog/plugins-for-mailman3/

• A plugin creator has many ways of "injecting" his code to run at certain phases of Mailman's operation, since Mailman looks for its classes and components dynamically, it doesn't care whether they are from a plugin or originally from core.

  • Implementing IHandler, IChain, IRule, IEmailCommand, ICLISubCommand or IStyle and placing modules containing the classes in the appropriate directories where Mailman finds them and instantiates them.

  • Implementing IRunner and adding the custom runner to mailman.cfg.

  • Implementing IArchiver and adding the custom archiver to mailman.cfg.

  • Implementing IMailTransportAgentLifecycle and setting the custom MTA in mailman.cfg.

  • Setting a custom callable in pre_hook or post_hook (only one callable per hook).

• Core config variable ext_dir is unused.

• There is not much documentation / examples of plugin creation, however core is very well documented so it's just a matter of figuring out what's pluggable or not.

Proposed changes

• Add configuration option similar to config.styles.paths to Handlers, Rules, Chains etc.. Which Mailman will use to look for components, so that plugins can just be accessible on the python path and not necessarily inside the Mailman package. Or use just one path per plugin and a standardized plugin structure:

  • plugin package
    • handlers
    • rules
    • chains
    • commands
    • pipelines
    • styles

• Let plugins add Pipelines the same way they can add Handlers etc...

  • This means refactoring BasePipeline, OwnerPipeline, PostingPipeline, VirginPipeline from mailman.core.pipelines.py into a package mailman.pipelines

  • Use find_components

• Let plugins subscribe to receive events.

• Let List creator specify List Style when creating it through Postorius.

• Allow multiple callables in pre_hook and post_hook run in order specified.

• Drop ext_dir.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

Hi all.

I have created a repository to keep the original proposal for this project, as well as the current working version and similar documentation / specs at:

https://gitlab.com/J08nY/pgpmailman-proposal

The repo contains up-to-date changes I propose to Mailman core to accommodate an encrypted lists plugin as well as other possible future plugins. (in core_changes.md) It also contains a current working sketch of the plugin (in plugin.md). Comments are very appreciated.

I wrote a post on the current issues I am facing on integrating the encrypted lists plugin with Postorius and HyperKitty:

https://neuromancer.sk/article/4

Integrating with Postorius and HyperKitty

Since a plugin-like out-of-tree approach is required for implementing encrypted lists into Mailman, a straight forward integration into Postorius and HyperKitty (as first proposed) by making them "aware" of the encrypted lists plugin is not possible.

Thus a new approach for providing their functionality and conforming to the project requirements is necessary. I see three possible pathways forward and a middle-ground between them.

## Standalone django app

A new django app will be created, using django-mailman3 as a base, that will implement all the web based functionality for encrypted mailing lists, such as:

• Displaying the List key for all public encrypted mailing lists.
• List key management for list admins
• User key management
• Encrypted archives, that are server unencrypted (effectively replaces HyperKitty for encrypted lists)

This app will then be run besides Postorius.

## A fork/patchset approach

This approach will create a fork of Postorius and HyperKitty that will integrate changes necessary for the encrypted lists plugin seamlessly. Thus users wanting to use encrypted mailing lists will have to setup Postorius and HyperKitty from this fork.

## Wrenching it in

This approach tries to integrate all of the functionality using configurable options of Postorius and HyperKitty. For example storing messages encrypted could be done via a custom django.db.backend. Receiving messages encrypted could be done via a small custom django app that will receive them, decrypt and pass to HyperKitty decrypted.

## A middle-ground

Somewhat of a middle ground seems to be most sensible. A standalone app will be necessary to provide functionality that is simply not possible to be integrated into Postorius and HyperKitty sensibly. This app will mostly provide key management (user and list), receive the messages encrypted and so on. However Postorius and HyperKitty will work with the least amount of "wrenching it in" as possible.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

Hi all.

Sending an update here along with a new blog post. https://neuromancer.sk/article/6

============================== GSoC 2017 - About the plugin

As last time I described outstanding PRs to Mailman Core and other Mailman's components, this time I am going to describe the plugin I am building on top of those components to enable PGP encrypted mailing lists.

In fact there are two plugins to present, with the first one being a general and quick plugin example that showcases how the new plugin API might be used and also provides some nice services for the PGP plugin.

mailman-rest-events

repo @ gitlab

This plugin subscribes itself to receive events in Mailman Core and sends them to urls configured. It is a variation of what mailman!264 is intending to do, based on the plugin API implemented in my MRs. It currently offers only basic functionality, a URL is specified in config per endpoint along with an API key (very similar to mailman-hyperkitty) and a regex of event class names that will be sent. The data sent currently is only the event class name in a JSON object. Config can have many endpoints specified with the form shown below.

[endpoints.django_mm3] url: http://localhost/django/api api_key: Something_secret_here events: .*

Results in a call such as this one:

POST /django/api?key=Something_secret_here HTTP/1.1 ... Content-Type: application/json

{"event": "DomainCreatedEvent"}

The plugin is currently very bare bones and proper serialization of events is underway. I am thinking of recursively serializing the non-private event attributes until an easily serializable object is reached, such as an Address or a MailingList or anything that has a unique string associated with it and can be queried using the REST API and such a string. So for example:

{ "name": "DomainCreatedEvent", "event": { "domain": "example.com" } }

or

{ "name": "AddressVerificationEvent", "event": { "address": "anne@example.org" } }

This plugin will be used by the mailman-pgp plugin to send events to django-mailman3 which will distribute them to Postorius, HyperKitty and the django app created to enable PGP encrypted mailing lists.

mailman-pgp

repo @ gitlab

First of all, I think I came up with a name that better fits with mailman-hyperkitty being an archiver "plugin" and in general with how plugins for projects are named in python (flask_ext_... and so on).

As the general functionality and layout of the plugin was already described I will mostly just summarise issues I am currently working on tackling.

low level PGP work

I originally proposed using python-pgp (https://github.com/mitchellrj/python-pgp https://pypi.python.org/pypi/py-pgp/0.0.1) to use to parse and create OpenPGP packets, as other libraries mostly offer only a high-level API or are not so feature rich. However this library seems quite un-maintained, so either a working fork should be established or a different library used. I am currently looking at both options. Will contact the original author as well as the current pypi package owner and see what's possible.

public key on subscription

Since a PGP enabled mailing list needs to know the public key of a subscribed address at the point when moderator approval is required, some mechanism to do so is necessary. This needs to happen before moderator approval, as the moderator / list owner should be able to see / download the provided key to verify it (or at least its fingerprint). Currently I see two options, an extension of the proposed key command or some changes to the current Subscription and Unsubscription workflows.

Extending the proposed key command would let the user use said command to send and confirm his public key, before a subscription to an encrypted list. This is similar to how schleuder does it. They essentially run somewhat of a mailing key-server where the users might submit keys via custom headers in message body.

However the current SubscriptionWorkflow and UnsubscriptionWorkflow are really close to being able to require a custom additional step during which the subscribers key is received and confirmed. Maybe making [Un]SubscriptionWorkflow pluggable components, that can be set on a per-list basis, similar to owner/posting chains or pipelines.

The second solution is definitely a more heavy-handed one, although might be a better one in the long run. As it allows plugins to provide [un]subscription steps which might be a nice use for plugins in Mailman Core. I can imagine for example subscription verification where the plugin verifies that the subscriber is a customer of some company by showing the user a confirmation token in the customer system etc..

require confirmation for all commands

To address replay attacks where an attacker listens on a user performing a command by sending it to the list_id-confirm address and then sends the same message again in the future to replay the command, all commands will need to require confirmation. This stops the attacker since he cannot obtain the cleartext of the message containing the confirmation token, or even if he could, he cannot forge the signature on the confirmation message (leaving endpoint security out-of-scope). To reuse the confirm command, Workflows and confirmation would have to be refactored out from subscription management.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

Hi all!

Another blog post is up. Copy follows for discussion. https://neuromancer.sk/article/8

PGP handling progress

This week things moved along with the mailman-pgp plugin. As I finally had a good PGP library to work with as well as some basic plugin API patches outstanding to Mailman Core.

So with that I implemented large parts of the mailman_pgp.pgp package, including tests, as well as a basic signature checking rule. Also, as the package now contains tests, I added a gitlab CI config and started running it.

repo @ neuromancer.sk repo @ gitlab

Wrappers

Created two classes, which wrap an email.message.Message instance (or mailman.email.message.Message) and expose a common public PGP handling API on said instance. One understands PGP/MIME (as per RFC1847 and RFC3156) and the other somewhat understands inline PGP. They both give methods to check presence of a PGP signed/encrypted message or PGP keys, to verify signatures of a message, to decrypt it or collect the attached keys. There are currently almost complete tests for handling signatures and partial for encryption.

MIMEWrapper

This one was rather easy to implement, as RFC3156 and RFC1847 are both very precise but also rather simple standards (well compared that to 90+ page RFC4880 [OpenPGP]).

InlineWrapper

As there is really no "Inline PGP standard" this wrapper improvises with how it looks for signatures/messages/keys. In it's current form it only accepts a non-multipart message and looks for ASCII-armored blobs in it.

Signature rule

The concrete way of integrating the PGP plugin into Mailman Core has changed over time. The original version of my proposal planned on working in the Mailman Core tree and as that changed to a plugin, new requirements of integration popped up, us stuff couldn't just be changed for this one plugin to work.

Because of the nature of encryption the PGP plugin needs to get it's hands on the messages before the rest of Mailmans rules. This could be done with a rule in a custom chain, however as I understand rules, they are, well, rules, they shouldn't change the message they are processing in any way. In my understanding of this architecture, if Mailman was written in a language with a const identifier, the message would have it in the chain links process method. It would work as a rule, just wouldn't feel nice and fit in with the architecture.

That's why I first wanted to implement all handling of incoming messages in a custom incoming runner. This runners class is then set as the runner for the in queue and the default runner is moved to another queue, perhaps in_default. The custom incoming runner does it's thing before passing messages back to the default incoming runners queue. However only encryption has this issue of needing to change the message, as rules and the rest need it in cleartext. So I decided to split off signature handling to a custom rule, and only handle encryption in the incoming runner.

I would like to get rid of the not-so-nice redirection of the default incoming runner altogether but I see no other way to decrypt the incoming message to a PGP enabled list before other rules get it.

The signature rule processes messages using the wrappers described above according to a per-list signature handling configuration:

Option | Default -------------------- | ------- unsigned_msg_action | bounce inline_pgp_action | None (pass-through) expired_sig_action | bounce revoked_sig_action | bounce malformed_sig_action | bounce duplicate_sig_action | bounce strip_original_sig | False sign_outgoing | False

I think the options are quite self-explanatory. They are checked in order and taken if the message matches the option and the set action is not None. So with the default configuration of the PGP enabled mailing list, an unsigned message will be bounced, inline PGP is allowed, signatures by expired keys are bounced (expired at time of checking), signatures by revoked keys are bounced, signatures that don't verify are bounced (maybe a better name for them than malformed?) and finally signatures that the Mailman PGP plugin already processed are bounced as well. This is to prevent replay attacks and is something I think people would expect Mailman to do, although I am not sure if the plugin should do it.

This signature rule is almost complete, with some edge-cases remaining and the checking of duplicate signatures also remaining.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

Hi all!

Checking in with progress around the halfway point of the GSoC 2017 timeline.

https://neuromancer.sk/article/12

====================== The point of no return

This week is around the halfway of GSoC 2017 project timeline, hence the title.

Key management

As I set out to do, I have now implemented most of the after subscription key management. The key change command. The pre subscription key management is done via a custom dynamically loaded subscription policy/workflow. This is possible with my pluggable-workflows branch/MR which introduces dynamically loaded workflows, which subscription and unsubscription policies are a part of.

Subscription

On subscription the PGP enabled mailing list needs a users public key. An example conversation establishing that follows (shows a list with moderation + pgp enabled subscription policy):

Mailman                                             User
-------                                             ----
list@example.com                                    anne@example.com
               <- subscribe                         1.


2.             key set "token1" ->
               + instructions to reply and attach user key
               (signed by list)


               <- key set "token1"                  3.
               (key attached as per RFC3156(PGP/MIME)
               or inline and we do our best to find it.)


4.             key confirm "token2" ->
               + statement containing "token2" and
               user key fingerprint in body, with instructions
               to sign it
               (signed by list, encrypted to user key)


               <- key confirm "token2"              5.
               + must contain signed statement from step 4
               (required to be signed by user key)


6.             ... the rest of the subscription steps (moderation) ...

Steps 3 and 5 can be optionally encrypted to the list key.

This workflow gives "some" assurance that the user really has the key she is subscribing with, however the trust in the address/user/key has to come from the list moderator and both my proposal and implementation rely on that. This workflow only proves that Mailman is communicating with someone that has the user key (can decrypt "token2" and sign the statement), not that that user is anne@example.com.

Key change

Works similar to the key set command on subscription. Works via a custom workflow, but not a subscription workflow/policy, just a workflow.

Mailman                                             User
-------                                             ----
list@example.com                                    anne@example.com
               <- key change                        1.
               (new! key attached as per RFC3156(PGP/MIME)
               or inline and we do our best to find it.)


2.             key confirm "token1" ->
               + statement containing "token1" and
               new! user key fingerprint in body, with instructions
               to sign it
               (signed by list, encrypted to new! user key)


               <- key confirm "token1"              3.
               + must contain signed statement from step 2.
               (required to be signed by old! user key)

Steps 1 and 3 can again be optionally encrypted.

This ensures that only someone with possesion of the old user key can change it. It requires the user to decrypt with the new key and sign a statement with the new key fingerprint as well as the token in it with the old key.

PyPi package

mailman-pgp @ PyPi I have now created a PyPi package for the mailman-pgp plugin as it's maturing, and while still unusable I wanted the name.

Test coverage

I got test coverage of mailman-pgp to 95% which now actually means something as large parts of the codebase are implemented and not just stubs. Since this plugin requires features not merged into Mailman Core (or PGPy) for pipelines to work I maintain forks of both with branches that merge all required branches into a plugin branch for Mailman Core and dev branch for PGPy.

Next up

Outgoing

I had a look at working in outgoing encryption of messages for pgp enabled mailing lists. Encryption cannot be done as a handler, as it requires to process the messages per-recipient or per-batch of recipients. The only configurable/dynamic option currently in Mailman Core is the [mta].outgoing callable. Which is not ideal since it itself has more functionality than simply dispatching to a correct Delivery instance based on the list configuration, that would have to be duplicated in mailman-pgp. The IMailTransportAgentDelivery interface looks promising though, so I'm thinking about refactoring the outgoing callable a bit to allow setting a custom one without the duplicities.

Signature hash tracking

To prevent replay attacks for things where always sending and requiring a signed confirmation token in response is not practically doable, the pgp plugin will keep signature hashes with timestamps and posssibly key fingerprints in a DB/some other quickly searchable structure, and will check signatures it receives against the hashes in that structure. It will then act accordingly, for example not allowing a user to post the same message (with the same signature) again, since it could have been replayed.

Documentation

I wanted to get the pgpmailman-proposal repository updated with current state/MRs but didn't get to it this week, so might find time for it over the weekend as well as for some code documentation.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

Hi all!

https://neuromancer.sk/article/14

================= Second evaluation

The second evaluation period came quite fast after the first one, nonetheless the project advanced much further so quick recap of its current state is in order.

Since first evaluation

SMTPS + STARTTLS

MR 286

Finally with working tests after upstream fixes in aiosmtpd.

Pluggable components (plugins)

MR 288

Rebased after the Click CLI processing branch was merged and got it to work nicely in the end. There was an issue with config processing, as plugins can now supply their own CLI commands and plugins are configured/specified in the Mailman core config, which can be supplied by a CLI option. So that created a bit of an argument processing/lazy-loading issue but looking some more at how Click works I was able to quickly resolve it. Config option is now an eager one and initializes Mailman before commands need to be listed/used.

Pluggable workflows

MR 299

Also rebased and added tests to get diffcov to 100% and fix one of the migrations in that branch, as it was broken before.

Key management (plugin)

Implemented email commands for managing per-address PGP keys in plugin. It uses pluggable workflows to plug into the subscription process of a PGP enabled mailing list and requests the user key, also does mailback confirmation of it. The key is then available to the list moderator during subscription moderation, and more generally to the plugin for verifying signatures and encrypting. After subscription key management is also implemented where a user can change his set key, provided he can sign a challenge provided by the plugin with the old key. Key revocation handling is also necessary, but not yet done.

Outgoing processing (plugin)

Implemented custom Bulk and Individual delivery classes for PGP enabled lists in plugin. These deliveries optionally encrypt the mail to subscribers keys, and/or sign with the list key. The bulk one retains anonymity of subscribers as the keyids are zeroed out of the PKESK(Public Key Encrypted Symmetric Key) packets which OpenPGP implementations should handle as a wildcard keyid and try decrypting with all usable private keys. It is also almost as efficient as it can be, as it only encrypts the message with one session key per chunk and then encrypts said session key to recipients in the chunk. The signing is also configurable.

Signature hash tracking (plugin)

Implemented store of signature hashes from successful postings to a PGP enabled list which are then (optionally) used to stop replay of the same signature by Mailman in a future posting.

PyPI package (plugin)

mailman-pgp @ PyPI

Created the PyPI package for the PGP plugin.

Overall

I would like to be a bit further in the project at this point, however I am very optimistic about the next days and weeks. After resolving some issues and TODOs I have for the current plugin implementation and setting up the live Mailman instance with the PGP plugin, which should be up by the end of the week. I believe I can start work on the other side of the REST API, of somehow hooking PGP enabled archives/lists to Postorius and HyperKitty.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

Hi all!

https://neuromancer.sk/article/16

================== Web UI integration

This post is about my current plans on how to implement the web ui part of PGP enabled Mailman. It strives to integrate into the Mailman Suite and use its features to the maximum possible degree.

General idea: Refactor general stuff to django-mailman3, to allow apps to hook up together in Mailman Suite easily, and then use that to hook up django-pgpmailman.

Features

Show PGP enabled public lists, with their key fingerprints, with the option to download their public keys, also show some of their configuration (so that subscribers can see that for example if they send a cleartext message to a list that requires encrypted messages, it will be bounced).

Enable list owner to configure the PGP related per-list configuration options.

Enable list owner to set/see the list key (private part). This is quite questionable and will have a site-level option to be turned off (the REST API will then not serve the list private key).

The same level of user key management as the key command allows, with similar steps during key change/revocation.

Implementation

Another django app is installed in the same project as Postorius + HyperKitty, django-pgpmailman. This app provides a list of PGP enabled mailing lists and their PGP related management in a similar way Postorius does, also user key management.

There are few places where Postorius refers to HyperKitty and vice versa, for adding the appropriate links/icons to the navbar as well as for the user menu entries. These references will be refactored to some mechanism in django-mailman3, which will allow any installed django app to add it's entry to the navbar or the user menu. This will allow django-pgpmailman to hook up rather easily, without any direct references to it from Postorius/HyperKitty/django-mailman3.

Archiving

The archiving web UI is a tougher nut to crack. I either have to develop a custom PGP mail archive frontend and integrate it similar to the PGP list management app, or integrate with HyperKitty transparently, so that archives are received encrypted, stored encrypted, and yet served to subscribers in clear. Developing a custom app is quite unrealistic and it would lack most HyperKitty functions.

However hooking up an encrypted message store to HyperKitty is also non-trivial, as HyperKitty is strongly tied with storing messages in it's database and using a django Model to represent a message.

I currently have no realistic ideas, one that comes to mind, is to create a custom django database backend, that somehow stores everything encrypted, but thats a very unwieldy solution that likely won't work well.

Other progress

Fixed many little issues with the PGP plugin and PGPy. Got it to work quite nicely, below you can see a message received by a subscriber, by a PGP enabled discussion list, encrypted to his key, as shown by Thunderbird with the EnigMail plugin:

https://neuromancer.sk/static/mailman_pgp_message.png

Also finally merged the finished key revoke command to mailman-pgp/master.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

Hi all.

https://neuromancer.sk/article/18

===================== Final work submission

As the GSoC 2017 final evaluation period just ended, my final work product is finally submitted. This post is a summary of my final work product.

Mailman-pgp

• https://gitlab.com/J08nY/mailman-pgp
• https://mailman-pgp.readthedocs.io/en/latest/
• Plugin for Mailman Core.
• Enables creating a PGP mailing list, which has a list key, can receive and serve messages encrypted, can sign and receive signed messages from subscribers.
• Creates the key email command, which is used for per-address user key management.
• Subscription to a PGP enabled mailing list the subscribing address to send and confirm an address public key, which the moderator must verify.
• Somewhat confirms the user has possession of the appropriate private key to the one sent on subscription.
• Has per-list settings for encryption/signatures/what to do with non encrypted / non signed messages, etc..
• Optionally exposes a REST API for list configuration.
• Has local archivers which can store the messages encrypted by the list key.
• Stores list and address keys in configurable key directories.
  • requires (some not merged) MRs in Mailman Core
    • mailman/pluggable-components, merged as mailman!308
    • mailman/list-style-descriptions
    • mailman/pluggable-workflows
    • mailman/pipelines-dynamical-instantiation, merged
  • additional MR (not required)
    • mailman/mta-smtps-starttls
• Required branches are merged and maintained at [J08nY/mailman/plugin.
• To install, do pip install mailman-pgp, warning: it will pull in a development version of Mailman Core and PGPy.

django-pgpmailman

• https://gitlab.com/J08nY/django-pgpmailman
• A Django app, uses django-mailman3 and mailmanclient, integrates well with Postorius and HyperKitty.
• Provides management of PGP enabled mailing lists to the list owner, and of PGP related subscription settings to the subscriber.
  • requires (currently not merged) MRs in mailmanclient, django-mailman3, Postorius and HyperKitty
    • mailmanclient/plugin-bindings
    • django-mailman3/template-chunks
    • postorius/template-chunks
    • hyperkitty/template-chunks

mailman-rest-events

• https://gitlab.com/J08nY/mailman-rest-events
• A plugin for Mailman Core that turned out to be unnecessary for the working of django-pgpmailman, but implemented a similar feature as this MR.
• This plugin sends the events (and some information about them) from Mailman Core to a list of configurable endpoints using JSON in HTTP POST requests.

Other contributions

• mailmanclient/split-sources, merged
• postorius/list-style-selection
• Many many PRs to PGPy, a Python only implementation of OpenPGP. 19 PRs and counting. As PGPy was not and still is not feature complete in regards to RFC4880 I found out many times that it's missing features/bugs broke mailman-pgp CI. It would not make sense fixing them locally, both from a software design perspective and open source software one aswell.

Overall

I think I met almost all goals that the project idea required and my original proposal stated, with the noteworthy exception of remote archiving to HyperKitty which I just couldn't find a way to integrate.

Cheers,

Jan

/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #