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: http://wiki.apache.org/apachecon/PgpKeySigning
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 ApacheFoo-1.2.zip 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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
