-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
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
-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
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
-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
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
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,
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
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
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
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
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
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
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
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
15 matches
Mail list logo
