incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru <>
Subject Re: key signing - issues
Date Sun, 07 Oct 2012 15:21:27 GMT
On 10/5/2012 8:04 AM, Benson Margulies wrote:...
 > As far as I can see, we don't do anything to facilitate or encourage
 > getting PGP keys signed. We tell people to create a key and put it in
 > the SVN 'keys' file.
 > Key signing strikes me as a bit of a conundrum for us. In all other
 > respects, we emphasize that anyone, anywhere, in any time zone, can be
 > a full member of a community. However, key signing requires something
 > else. [1] Generally, it requires a face-to-face interaction.

This is fundamentally two separate issues:

1- Explaining the importance of the PGP Web Of Trust and how it relates 
to the security of downloads from Apache projects, both to our 
committers/contributors and to our users.

While "web of trust" may be familiar to many of us, I don't think it's 
importance and details are familiar with many software users.  This is 
an area that I'd support folks going off and JDFI by making patches 
against things like /dev/* and the incubator website, both for really 
clearly written "how do I..." steps, as well as "why do I care" things.

And yes, putting in a big note about promoting keysignings at 
Apache-related events is key.  Virtually every ApacheCon has had a 
keysigning party, and it is usually emailed to committers@... but 
sometimes not until the last minute.  8-)
See also:

2- Better providing assurances to the users of Apache projects that the 
software they download is legitimate.  This is a much bigger problem.

It's great that "we" know that is the correct 
download, because we know what PGP is and know someone who knows someone 
who signed the Foo release manager's key.  But that chain of information 
is actually very little use for the 99% of Apache software downloading 
human beings, who have no clue - nor do they particularly care - who 
"we" as individuals are.

Fundamentally, the ASF does not really *directly* provide assurances to 
our users that their downloads are legitimate.  Instead, we rely on the 
social contract that PMCs know how to run projects, and that they 
properly manage their release managers.  It's the release managers who 
sign downloads as *individuals* that is the tie the actual end user has 
between the .zip/.tar.gz and the fact it came from our organization.

A classic solution to this is as Benson suggests: have a role account 
that is specifically tied to the ASF as an organization that provides 
this link.  I.e. signed .zip -> RM key -> secretary@ key -> official ASF 
officer.  This has been suggested a number of times before in several 
different contexts (PGP, Windows authentication, Java/JAR signing, etc.) 
and has never made real progress.  Two key issues are:

2a- Organizational security and reputation.  I.e. how do we both 
securely (really securely) store a secretary@ key, and how do we ensure 
we have policies that reliably ensure our release managers are properly 
following Foundation policies?  That's a big organizational question the 
members and board would have to be comfortable with.

2b- Demonstration of need.  The ASF is big enough that just neat ideas 
that are useful aren't necessarily enough to "just make things happen". 
  There needs to be a clearly expressed and specific need that an actual 
Apache project has now, before we will often have the organizational 
will and energy to make a concrete change.

This one I think is hard to quantify, but to me at least, is hugely 
important.  We provide software for the public good - often in very easy 
to use ways.  But our security mechanism for validating downloads is 
*not* easy to understand or use.  Given the importance of Apache 
software products in today's computer ecosystem - both traditional 
(running servers) and newer stuff (Apache OpenOffice anyone?) - 
personally I think it would be really nice to figure out how we can make 
it *easy* and *trustable* for end users to know they're getting the 
right software.

Does that separation of two issues make sense?  I'm not the 
infra/downloads/keys expert personally these days, so unfortunately I 
can't go lead this effort, but I do want to be sure we try to keep 
issues like this very clear, both to understand them, and to understand 
the specifics of what our actual Apache projects need (so that then the 
ASF as an organization can better decide how to help them).

- Shane

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message