[Mailman-Developers] Public-key signing+encryption plugin API foreseeable needs
J.B. Nicholson
jbn at forestfield.org
Thu Mar 16 23:31:33 EDT 2017
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.
More information about the Mailman-Developers
mailing list