This thread is a continuation of this one: https://mail.python.org/pipermail/mailman-developers/2011-May/021377.html .
Hi
What is the current status of this issue? Is there going to be GnuPG support in Mailman 3?
-- http://people.eisenbits.com/~stf/ http://www.eisenbits.com/
OpenPGP: 80FC 1824 2EA4 9223 A986 DB4E 934E FEA0 F492 A63B
Hi,
On 13/06/2014 09:33, Stanisław Findeisen wrote:
This thread is a continuation of this one: https://mail.python.org/pipermail/mailman-developers/2011-May/021377.html .
I found this page yesterday, as we were doing a key signing party…
http://security.stackexchange.com/questions/26544/gpg-encrypted-mailing-list...
Your are speaking about "2. Do a relay.", right?
Regards, Sylvain.
On 2014-06-14 10:47, Sylvain Viart wrote:
Yes, except we don't want to use the mailing list maintainer keys, or make him manually decrypt/encrypt every message. This should be done automatically by Mailman, and we want to use the mailing list keypair.
This could be customized. For example, see "new list settings" here: https://bugs.launchpad.net/mailman/+bug/558189 . This scheme could be made quite flexible. For example sending messages encrypted with some people keys (but not the list key) could also be allowed, thus alleviating the problem of the list maintainer being able to inspect (and possibly block) every message.
Anyway it is crucial that the original signatures are retained, IMHO. Not sure what would be the problems with double-signed messages, but ideally the Mailman would add its own signature, too.
Also, the technical messages to/from Mailman (like the monthly ML password, or ML commands) should also be encrypted and/or signed.
-- http://people.eisenbits.com/~stf/ http://www.eisenbits.com/
OpenPGP: 80FC 1824 2EA4 9223 A986 DB4E 934E FEA0 F492 A63B
Le 14/06/2014 19:49, Stanisław Findeisen a écrit :
Sorry, of course it should be done by the list engine. Only the concept of relaying…
This question of distributing encrypted email to an unknown number of subscribers is quite interesting/dangerous in the point of view of securing the information. Do you agree? Not saying it couldn't be accomplished of course.
The reply of the question linked above said:
"When a secret is known by more than two or three people, it is no longer a secret, merely /discreet/. Any recipient of the mailing-list, by definition, can read all messages, hence he is *trusted* (in the sense of: he has the power to betray you). "
Could you describe the goal to achieve? It seems really interesting, but I've the feeling that keeping the encryption chain will be quite difficult.
And you probably know that the encryption is as strong as it weakest point in the chain.
Also I noticed that despite we are in 2014, using GPG is still quite "repulsing" for basic user…
Sylvain.
Sylvain Viart writes:
True, but this is out of scope for this list. I'm not saying you shouldn't discuss here if you want to, just that from the point of view of the Mailman developers we are assuming that users have answers to (enough of) that set of questions, and we're merely interested in how much demand there is.
Could you describe the goal to achieve?
One goal that Mailman is interested in is chaining trust, via signatures. I think it's reasonable to suppose that if the original user is supposed to sign her post, and the list verifies and resigns, we might be able to convince some sites to whitelist those lists.
That would be worthwhile even if we never do really solve the issues of encrypted mailing lists. I'm not sure if there are any issues with encrypted lists that don't come up with signed lists (well, I guess there's the issue that signed lists are useful to users even if they don't use a PGP tool, but that's definitely out of scope for us).
Also I noticed that despite we are in 2014, using GPG is still quite "repulsing" for basic user…
Sure. There's obviously no hope of getting enough yahoos[1] to sign mail that Yahoo! will give up on "p=reject". ;-)
Footnotes: [1] http://dictionary.reference.com/browse/yahoo. Appropriate, eh? Note that Yahoo! almost certainly intends a different etymology....
Le 15/06/2014 11:18, Stephen J. Turnbull a écrit :
[distributing encrypted email to an unknown number subscribers…] True, but this is out of scope for this list.
Just to emphasis that the goal of keeping information private that way could be wrong, if done the wrong way. (For example, you may not want to store a clear temporary file of the decrypted email, on the server hard drive.)
I totally agree that from the point of view of software developer the perception can be different. May be, I didn't say that clearly but it's a very interesting challenge to bring cryptography and mail distribution to some more simplicity… while keeping the chain of trust. :-)
yahoos :[1] http://dictionary.reference.com/browse/yahoo
Oh lovely! Thanks for sharing. :-D In French I may say "propos croustillants" (crunchy).
Regards, Sylvain
Sympa does something like this with S/MIME. Incoming list messages are encrypted to the list's key, the list decrypts it and reencrypts it to the subscribers keys and sends it back out. S/MIME allows one message to be encrypted to multiple recipients' keys and I don't know whether it makes up one message with everyone's key, or separately encrypts each copy.
It is my impression that this feature is in regular use in Europe. Have you checked to see what people's experience with it is?
R's, John
On 2014-06-14 13:11, Stephen J. Turnbull wrote:
What needs to be done? Where is the code?
-- http://people.eisenbits.com/~stf/ http://www.eisenbits.com/
OpenPGP: 80FC 1824 2EA4 9223 A986 DB4E 934E FEA0 F492 A63B
Stanisław Findeisen writes:
What needs to be done? Where is the code?
Pretty much everything. In particular, key management is not at all useful last I heard, you need to load the keys by hand into a file on the server or something like that. It wasn't integrated into the account management interface.
The most recent code is presumably in Abilash's repo on Launchpad. I'll find it for you later (have an appointment right now), but you can look in the list of branches for the Mailman project on launchpad.net.
Hi,
On 13/06/2014 09:33, Stanisław Findeisen wrote:
This thread is a continuation of this one: https://mail.python.org/pipermail/mailman-developers/2011-May/021377.html .
I found this page yesterday, as we were doing a key signing party…
http://security.stackexchange.com/questions/26544/gpg-encrypted-mailing-list...
Your are speaking about "2. Do a relay.", right?
Regards, Sylvain.
On 2014-06-14 10:47, Sylvain Viart wrote:
Yes, except we don't want to use the mailing list maintainer keys, or make him manually decrypt/encrypt every message. This should be done automatically by Mailman, and we want to use the mailing list keypair.
This could be customized. For example, see "new list settings" here: https://bugs.launchpad.net/mailman/+bug/558189 . This scheme could be made quite flexible. For example sending messages encrypted with some people keys (but not the list key) could also be allowed, thus alleviating the problem of the list maintainer being able to inspect (and possibly block) every message.
Anyway it is crucial that the original signatures are retained, IMHO. Not sure what would be the problems with double-signed messages, but ideally the Mailman would add its own signature, too.
Also, the technical messages to/from Mailman (like the monthly ML password, or ML commands) should also be encrypted and/or signed.
-- http://people.eisenbits.com/~stf/ http://www.eisenbits.com/
OpenPGP: 80FC 1824 2EA4 9223 A986 DB4E 934E FEA0 F492 A63B
Le 14/06/2014 19:49, Stanisław Findeisen a écrit :
Sorry, of course it should be done by the list engine. Only the concept of relaying…
This question of distributing encrypted email to an unknown number of subscribers is quite interesting/dangerous in the point of view of securing the information. Do you agree? Not saying it couldn't be accomplished of course.
The reply of the question linked above said:
"When a secret is known by more than two or three people, it is no longer a secret, merely /discreet/. Any recipient of the mailing-list, by definition, can read all messages, hence he is *trusted* (in the sense of: he has the power to betray you). "
Could you describe the goal to achieve? It seems really interesting, but I've the feeling that keeping the encryption chain will be quite difficult.
And you probably know that the encryption is as strong as it weakest point in the chain.
Also I noticed that despite we are in 2014, using GPG is still quite "repulsing" for basic user…
Sylvain.
Sylvain Viart writes:
True, but this is out of scope for this list. I'm not saying you shouldn't discuss here if you want to, just that from the point of view of the Mailman developers we are assuming that users have answers to (enough of) that set of questions, and we're merely interested in how much demand there is.
Could you describe the goal to achieve?
One goal that Mailman is interested in is chaining trust, via signatures. I think it's reasonable to suppose that if the original user is supposed to sign her post, and the list verifies and resigns, we might be able to convince some sites to whitelist those lists.
That would be worthwhile even if we never do really solve the issues of encrypted mailing lists. I'm not sure if there are any issues with encrypted lists that don't come up with signed lists (well, I guess there's the issue that signed lists are useful to users even if they don't use a PGP tool, but that's definitely out of scope for us).
Also I noticed that despite we are in 2014, using GPG is still quite "repulsing" for basic user…
Sure. There's obviously no hope of getting enough yahoos[1] to sign mail that Yahoo! will give up on "p=reject". ;-)
Footnotes: [1] http://dictionary.reference.com/browse/yahoo. Appropriate, eh? Note that Yahoo! almost certainly intends a different etymology....
Le 15/06/2014 11:18, Stephen J. Turnbull a écrit :
[distributing encrypted email to an unknown number subscribers…] True, but this is out of scope for this list.
Just to emphasis that the goal of keeping information private that way could be wrong, if done the wrong way. (For example, you may not want to store a clear temporary file of the decrypted email, on the server hard drive.)
I totally agree that from the point of view of software developer the perception can be different. May be, I didn't say that clearly but it's a very interesting challenge to bring cryptography and mail distribution to some more simplicity… while keeping the chain of trust. :-)
yahoos :[1] http://dictionary.reference.com/browse/yahoo
Oh lovely! Thanks for sharing. :-D In French I may say "propos croustillants" (crunchy).
Regards, Sylvain
Sympa does something like this with S/MIME. Incoming list messages are encrypted to the list's key, the list decrypts it and reencrypts it to the subscribers keys and sends it back out. S/MIME allows one message to be encrypted to multiple recipients' keys and I don't know whether it makes up one message with everyone's key, or separately encrypts each copy.
It is my impression that this feature is in regular use in Europe. Have you checked to see what people's experience with it is?
R's, John
On 2014-06-14 13:11, Stephen J. Turnbull wrote:
What needs to be done? Where is the code?
-- http://people.eisenbits.com/~stf/ http://www.eisenbits.com/
OpenPGP: 80FC 1824 2EA4 9223 A986 DB4E 934E FEA0 F492 A63B
Stanisław Findeisen writes:
What needs to be done? Where is the code?
Pretty much everything. In particular, key management is not at all useful last I heard, you need to load the keys by hand into a file on the server or something like that. It wasn't integrated into the account management interface.
The most recent code is presumably in Abilash's repo on Launchpad. I'll find it for you later (have an appointment right now), but you can look in the list of branches for the Mailman project on launchpad.net.
participants (4)
-
John Levine -
Stanisław Findeisen -
Stephen J. Turnbull -
Sylvain Viart