Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Stefan Schlott
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25.04.2013 15:35, Daniel Kahn Gillmor wrote: > abhilash might have meant that there is a concern that a decrypted > message could be stored *on disk* in one of the queues, not just > in memory. Of course, it's a good idea to decrypt the data as l

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Stefan Schlott
On 25.04.2013 21:10, Abhilash Raj wrote: >> Abhilash, i don't see any mention in your proposal of how you plan to >> deal with the secret key material. will there be a way for mailman to >> use a secret key that is stored in a password-protected form? If so, how? >> >> Well I am not quite profic

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread 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 thi

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Terri Oda
On 04/26/2013 12:45 PM, Barry Warsaw wrote: 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. I've been wondering about that... i

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Abhilash Raj
-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: > > > - di

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Terri Oda
So... What have we decided? :) From my fuzzy "I read my email on a plane after delta woke me up at 3am to tell me my flight was cancelled" level of recollection The few things I we actually agreed on: - We like the idea of a rest interface. - That interface/API should probably be decided

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Stefan Schlott
On 26.04.2013 20:55, Terri Oda wrote: > I've been wondering about that... is there any time when the encrypted > message on disk would be available but the private key not? As already pointed out, there are (at least) two ways to avoid an unprotected secret key (or the corresponding pass phrase,

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Abhilash Raj
Hi all, I wrote a brief summary[1] of this thread. Its in the form of notes sorted according to participants and a small summary at the end( showing off whatever I could understand reading the thread twice from head to toe ). However I might have misunderstood ( or not understood at all ) or missed

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Richard Wackerbarth
Abhilash, Thanks for the summary. Let me add a bit about what I think we should present in this interface. First, it should be RESTful and self documenting. The format of information delivered will be controlled by the http Accept: header The standard representation for communication between v

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Stephen J. Turnbull
Stefan Schlott writes: > 2. Your list has elevated security requirements. In this case, you can > use gpg-agent to manage the secret key (and its passphrase). I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to th

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Stephen J. Turnbull
Barry Warsaw writes: > 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. It's worse than that. The attacker doesn't need

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Stephen J. Turnbull
Richard Wackerbarth writes: > subscription - the binding of an email address to a list. Also preferences are bound here. (This is not the only kind of thing that preferences can be bound to, but experience shows that we need per-subscription preferences.) > First, rather than having multiple

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Daniel Kahn Gillmor
On 04/27/2013 01:36 PM, Stephen J. Turnbull wrote: > without a complete redesign starting > from the assumption of encrypted messages whose plain text must > be exposed as briefly as possible. At least one project suggests that it may be possible to operate an encrypted mailing list such that the

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

2013-04-26 Thread Daniel Kahn Gillmor
On 04/27/2013 12:45 PM, Stephen J. Turnbull wrote: > Stefan Schlott writes: > > > 2. Your list has elevated security requirements. In this case, you can > > use gpg-agent to manage the secret key (and its passphrase). > > I don't understand what threat you propose to address in this way. > It's

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Stephen J. Turnbull
Abhilash Raj writes: > Hi all, > I wrote a brief summary[1] of this thread. You've misinterpreted or mistyped a couple things I wrote: I'm not against OAuth in general, just against Mailman being an OAuth *provider*, or bundling one, because we can't support it properly. Users should get auth