www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject Re: Secure submission of sensitive data to committees/entities
Date Thu, 24 Apr 2014 19:48:43 GMT
On 4/24/14, 12:01 PM, Mark Thomas wrote:
> This service needs to be limited to only those PMCs (or other entities)
> that have explicitly requested it and are therefore expected to be
> capable of correctly handling OpenPGP encrypted email.


> I'm concerned that enabling by default for all PMCs creates as many, if
> not more, problems than it solves. The majority of commiters, members
> and PMCs are not capable of correctly (i.e. securely) working with
> OpenPGP as we see every time we have an enforced password reset.

Being able to deal with this mail should be pretty easy for anyone.  If your
mail client doesn't support encrypted mail you can simply copy the encrypted
portion out run gpg on the command line, paste the message in, respond to the
prompt to provide the passphrase to your key, and finally hit Ctrl+D.  Those
basic instructions could easily be included in the plain text portion of the email.

This problem is ultimately a chicken or egg issue.  If you don't start sending
people encrypted mail they have no incentive to learn what to do with it.  If
they don't know how to receive it you'll probably avoid sending it.  If you
want people to learn how to deal with the mail, start sending them encrypted
mail on a more regular basis.

> Limiting the service to PMCs that grok OpenPGP removes a lot of the
> problems but a number of issues remain. The ones I can think of right
> now are:
> - It renders part of the PMC archives inaccessible to ASF members
> - It renders part of the PMC archives inaccessible to the ASF board
> - In the worse case scenario where every PMC members loses their
>   private key it renders the PMC archives inaccessible to anyone.
> - None of the previous issues I am aware of where private information
>   was mis-handled would have been prevented by this system
> - This looks like a solution in search of a problem. I'm aware that this
>   was requested by a PMC but I'm not convinced that that request is
>   backed up by a genuine use case nor that the effort involved in
>   creating and, more importantly, maintaining this service is justified
>   by the benefits it would provide
> 
> (Yes, some of the above is solvable by encrypting to a key accessible by
> root, by sending a non-encrypted version to the archive, etc.)
> 
> Let me approach this another way.
> 
> What security risks is this system attempting to mitigate? That
> information sent by by some random, external, non-security savvy person
> is encrypted and unreadable while in transit? What information is
> expected to be sufficiently valuable that someone (from a malicious user
> in an internet cafe to a nation state) is going to want to the trouble
> of intercepting it?
> 
> Whichever way I look at this, I am having a hard time coming up with a
> requirement that justifies the ongoing maintenance costs (I'm ignoring
> the initial development effort since most of it has been done and
> because this looks like an itch you want to scratch).
> 
> If this is a service that has only been requested by a single PMC then
> perhaps that PMC should take on the responsibility of creating and
> managing this service rather than passing it to infra.
> 
> Mark
> 


Mime
View raw message