-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Everyone was sending singed messages so i thought to send one too ;-), Though my public keys are not available at any key-server.
On Saturday 27 April 2013 12:15 AM, Barry Warsaw wrote: > 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. I did think about this part but discarded it on base that is it really worth it to decrypt the message multiple times? While talking to Stephen he suggested that keys could be stored in a more secure database than the main database whose permissions are much higher. So accessing the keys from multiple points( once from each queue ) may increase the chances of attacker getting success? > 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. > That always remains the risk that if one part of the server is compromised its easier for the attacker to access other parts but still should we not try to secure both( private key and decrypted message ) so as to increase complication for attacker? > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 Thanks Abhilash -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRes8qAAoJEPVZtmCk10dUwNIH/jsLoEfFHqu6kFpwgkp+vjC+ sTR8f8QYovkARvaAhOSSlgFwCQw9dQnIwzIkitOQCxtdpQMSr4JJPpvw9AaeY/ik /C+IGg18/ypfOA4FxK/T75ZpincxovB+HkTNS0xwTbyhr3/5KfwqYdC6PcF6f/Ea 5Drqsr7QwQO3X+pv30aoDunJ6/th2P1p1PgM2juBUdtpXPwL0FFTa9QkcAoRv9Sx V7e+ofu7nWF6M7dKDP7eYIJDL7oiNJJTSiz+VdiK7FqfgSq6UUMvoTgyd0l2NDZr MSiS8Kq1Hcm/C/RpUOiEuZzTBNw5nPMBx8fKWtcyo6TTrmQNy3mOHCAnCsoT4po= =Lk6Z -----END PGP SIGNATURE----- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9