[Mailman-Developers] GSOC Project idea: OpenPGP integration

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Apr 26, 2013, at 02:09 PM, Stefan Schlott wrote:

>- disk queue. I don't remember if mailman persists received (but not
>yet sent) mails on disk.
>
>Addressing the last point, you can either choose to decrypt the mail
>in a later stage, or (if this is a bad idea for performance reasons)
>deal with this problem with an adequate system configuration, although
>this is tricky and certainly error-prone. But I think it could be done
>by excluding the queue from backup (unless, of course, the backup is
>encrypted, which you should do anyway) and having an encrypted file
>system.

Yes, Mailman caches the messages and the metadata as it transfers the message
from queue to queue.  These two pieces of information are what make up the
.pck (Python pickle) files in the queue directories, so for example, after the
message has been moderated, it lives in a pck file until the modification
runner picks it up for processing.

One option, which might suck performance-wise, would be to decrypt the message
multiple times.  Thus the moderation queue runner would decrypt the message if
it needs to make moderation decisions based on the encrypted payload (it may
not need to though, since a lot can be discerned from the headers and other
cleartext information).  If it decides that the message is okay to post, it
would not store the decrypted message in the queue, but instead the original
message with the encrypted payload.  The next queue runner would then also
have to decrypt the message to do its processing.

OTOH, maybe that's all security theater.  If the Mailman system's private key
is available to an attacker, then having the encrypted message on disk
temporarily is probably not going to stop them from decrypting it.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRess/AAoJEBJutWOnSwa//rcQALx/p1Ba8a4CZWCzL2FGW+PZ
80mP+prL44VisScEJopqxx2vzCmzRNo8w0uH7UwKc2DQ4Bl8O+LdBoZs3UdZAB/9
dgSxIAMFsy78TnVngif3Ps5gESdQUAuLijkViHJGePcKNDXMYMV4hBzeqKZxCj+Q
Y1NxyJLLeuLrt3HEvQy4TAmWFA/r4UGG5QM249orv2iOtXeHlGMD+IUi4pqyolY6
qzK6WirEh+ntGLvsXHuIBSxpidG9UvRe4XmLT7/fVAUO6X5EuTBdk9NgT9d+Pw+Z
eslyngqPOf2MvV/wKLzZFytblGFog7pLOkOPbJ1UzI+KxIf8K4LMlEUG5mo2IGY+
7vOZgsD9dxzJ2kX0uk1SFR4b23jWZhrYwHAC/k03x2l3FoMvdUqb5/9+nf6C+/4K
ZyeB+exOD33TkKtTSx5iZ8HEO/1vCsENFESLeZ5M79cXQJKihyRMiAQfHXzQfR65
XZ0lCG4SB3c0QmhBSqWTxdNP01In0YcD0E5S+1JlP7HbCRhKTU0oHy45rMVSwKfC
h1luVZe74Ecuy0foL2gcNObJG6GrXEsAUfYXL5TIy8vSff5VuNVyP4j0Xq7pmPxN
XzEt0Vyyc3GTrHbBbnkX1gM4W3icxSHCt9mvCDZ8Civ46qR2pJjkTg6laPtHfLWB
02sufu7o47Z3xcGM4rbq
=pajO
-----END PGP SIGNATURE-----