www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Secure submission of sensitive data to committees/entities
Date Thu, 24 Apr 2014 19:01:06 GMT
On 23/04/2014 18:18, Daniel Gruno wrote:
> Hello, infra-dev lurkers,
> 
> As was seen in the latest board report (should be public in about a
> month, if you're not on the infra ML), there was a request from several
> people at ApacheCon for infra to create a tool that automates secure
> submission of data of a sensitive nature to PMCs or other entities in
> the foundation, and we'd like some feedback on this.

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.

> We have put up a solution for this at https://secsubmit.apache.org/ that
> does the following:
> 
> 1) Jane Doe has something sensitive she wishes to share with the PMC and
> only the PMC (or another entity within the ASF)
> 2) Jane visits SecSubmit
> 3) Jane selects project Foo
> 4) Jane enters the data she'd like to send
> 
> 5) The site fetches the PGP keys associated with members of this PMC
> 6) The site composes an email to the PMC/entity
> 
> 7.a) The site encrypts this using the PGP keys and sends it to
> private@foo.apache.org (or security@ if applicable)
> 7.b) In cases of security issues (exploits etc), the Apache Security
> Team is also CC'ed and their keys are coupled in.
> 7.c) The site also informs the PMC/entity about the current PGP status
> of the respective PMC/entity (how many have valid keys etc)
> 
> This process can already be done manually by anyone, this site simply
> automates it, making it easier to send encrypted information to an
> Apache entity.
> 
> Note: Currently, the submissions end up in my inbox, it is not enabled
> for projects yet. We'd like some feedback before we activate the service
> for the public. If you'd like to see the end result of a submission,
> please ping me on #asfinfra, and I can flip some bits to make it land in
> your inbox.
> 
> Also note that this is NOT a replacement for security@. If people use it
> for submitting security flaws, so be it, but the original intent is to
> make it easier to submit confidential information of any character to a
> PMC or other entity in the ASF, whether it be a bug, someone dying of
> cancer or what have you, and be assured that only the PMC can read it,
> even in cases of compromised email transport or clients.
> 
> What do you think? Is this something you could imagine using (or imagine
> others could use), or is it simply a waste of space?

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.

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