This update goes with my latest blog post about finding a good PGP python library:
https://neuromancer.sk/article/7 (!the blog posts content is not equal to this post!)
Along with that I also implemented list keypair generation in the mailman_pgp plugin. It is configurable (key type, key size) in the plugin config and currently produces keys such as this one:
pub rsa4096/0x539FD576AA401697 2017-06-19 [SC] 5B810BA0660C2EBCF46B3354539FD576AA401697 uid [ unknown] Zzz firstname.lastname@example.org uid [ unknown] Zzz email@example.com sub rsa4096/0x0AC655A0580B8CE6 2017-06-19 [E]
This keypair generation is done via spawning another process on encrypted list creation. Since the process might take quite some time, it would create problems if, for example, the encrypted list was created by the REST runner which would then go off to create the keypair for a few seconds while requests keep timing out.
I also implemented PGP/MIME and inline PGP utilities. They can check whether a message is signed/encrypted as per RFC1847+RFC3156 for the former, and per some custom strict rules for the latter(inline PGP). They can verify/decrypt both PGP/MIME and inline PGP messages. These use the PGPy library I found and blogged about.
After reading through some more of the discussion on mailman-developers around GSoC 2013 OpenPGP integration, I've chosen to refine some of the handling of both signatures and encryption in the PGP plugin, to address some of the questions/concerns. Here I specify a high level overview of signature handling, i.e. what should happen, not how should it be implemented.
# Assumes mailman_pgp already has a confirmed users public key.
User signs his message, either via PGP/MIME or inline PGP.
Sends to list posting address.
passed it directly to the default incoming runner. Else go-on.
unsigned_msg_action is taken.
inline_pgp_action is taken.
malformed_sig_action is taken.
revoked or expired. If so the
expired_sig_action is taken, respectively.
of them mailman_pgp ever saw. If it finds it, then the
duplicate_sig_action is taken.
^^ I am not sure about this step ^^. It was proposed in the 2013
discussion, to avoid replay attacks on posting (replay attacks on
commands are solved by requiring confirmation).
is considered a good posting as far as mailman_pgp is concerned.
message body and stored in
msgdata and the cleartext of the message
remains in the message body.
the multipart/signed (as per RFC1847) with the signature ASCII-armor
msgdata and only the inner part of the first payload as the
strip_original_sig, go-on. If not
attach the signature from
msgdata back to create a PGP/MIME signed
message. (don't output inline PGP...)
sign_outgoingadd another signature
packet from of the mailing lists private key signing the message body, to the signature ASCII-armor.
received to stop replay attacks on posting? A replay attack on posting without it is trivial.
perspective per user makes more sense, as PGP keys have more user-ids, so a user just sets up his key once, and it covers addresses in all his user-ids. However per-address is more flexible, and the keypair must be confirmed per-address anyways. A subscription is also per-address(a user through a preferred address).
and expired sig_action could be merged, maybe even malformed.
it to the rest of Mailman core?
Jan ______________________________________________________ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__/__\ #