Barry Warsaw wrote:
Does that make it worth it to add as a supported feature in the core? It depends. What I would be very interested in -at least as a first step- are ways to enable experimentation into such features by the addition of hooks and APIs that allow third-party plugins that could support this feature. Presumably such plugins would have utility for other use cases too.
I was thinking this same thing; if Mailman had such hooks and an API allowing people to write plugins, everything discussed in this thread so far could be done with a plugin.
The overall goal for this plugin's API needs is to allow a Mailman admin or list owner to install this plugin and see the normal Mailman UI change slightly in relevant places to accommodate the needs of public keys.
Such a plugin for this task would need to:
have read access to each inbound message sent to a list where this plugin is supposed to be active. This is used to check a signature and possibly decrypt a message intended for list consumption when people send commands to the list encrypted with the list's public key.
somehow signal acceptance/rejection (to the next stage in Mailman's normal processing queue) of a message as coming from a subscriber (for lists where only subscribers may post) or a suitable other user (for lists where non-subscribers may also post).
get read/write access to each outbound message from a list before it is mailed to subscribers. This is where the list-signing + encryption would be done.
make a list command (even one that overrides the normal Mailman list commands) so one could do things with public keys relevant to this plugin -- subscribe to a list and supply either a pointer to or a copy of a public key at the same time in the same subscribe command, for example. I imagine there would be other commands that need similar public key additions to syntax.
be able to add fields, table columns, and form elements to an extensible web UI so key-related functions and displays can be integrated into extant displays -- subscribing on the web should include a prompt where one uploads one's public key or provides a URL where Mailman can fetch said public key. Getting a list of subscribers (if that's allowed per list policy) should include perhaps the key signature of each subscriber (if that subscriber is okay with publishing that info), the subscriber info for each list should include a setting where each user can decide if they want the list to publish the key signature (I think this is akin to current Mailman asking about hiding the user's identity in the subscriber's list), etc.
a way to place the list's public key in a file everyone could read at a predictable static URL. MUAs would use this URL to automatically fetch the list's public key.
a way to add to the documentation describing the plugin's added functionality; best would be to not have to replace extant documentation pages, but add pointers in current documentation pointing to new pages (which are installed in a place along side extant docs).
The plugin might also need an acceptable place on the server to store state data: a GPG keyring holding a copy of each subscriber & moderator's public key, the list's public and private keys, and some temporary space where the list can do work signing+encrypting messages (or perhaps GPG has a better way to handle this and the plugin should use whatever GPG provides).
I'm not familiar with Mailman's current hooks/API to know if any of this already exists, or is in-line with how Mailman generally does things.
Functionally, the list needs to inform all subscribers of the new list public key each time it changes. Maybe that is done with a header in a post with the list's public key's signature (saying the key with this signature was used to sign+encrypt this message) and it would be up to the MUA to get (and cache) the appropriate public key to verify this post?
There are also some policy issues I raised in another post on this thread regarding GPG's support for: obsolete hash/encryption algorithms, how this project wants to handle list archives (particularly re-signing+encrypting list archives). I think those issues should be considered. They seem to me to be important factors in how everyone interested in the list would use the list.
Finally, I'm not sure what the goals for the project were in the first place and the goals I posted are really only things I think are possible to implement.
Here's another of my guesses aimed at succinctly describing what this project will do: replace the subscription and posting filtering mechanism (currently based on email address string comparisons) with public key cryptography; if one sends in a post from any email address signed (or signed+encrypted, as per list policy?) with the right public key, that post is deemed to come from a subscriber. Other posts are handled in accordance with list policy.
If the project leader could speak to the project's goals, it might help us all understand what's in and out of scope for the project.
Also, thanks for letting someone completely unconnected with this project chime in out of nowhere.