When you receive a signed message, or obtain signed software, you can find
out which key signed the message or the software, and retrieve the key
from the keyserver. The key contains the name and email address of the supposed
owner of the key.
Of course you may believe that the person named in the key, actually is
the owner of the key. If you are a little more suspicious, you can use the
web of trust to raise your confidence regarding the owner of the key.
A pgp path finder is software used to find shortest paths
from one key to another, for instance from your key to the key used
to sign some message or software.
This only works for keys in the strong set.
The web of trust does only one thing: it helps you to establish
that some given key actually belongs to the person named in the key;
nothing more, nothing less.
If you receive a siged message or obtain signed software, you have to
use other ways to establish that, for instance, the message is
true or that the software works.
The web of trust doesn't help you in your decision to believe
or not believe the message, to use or not use the software.
When the Apache Software Foundation was
announced (June 1999), Brian Behlendorf supposedly said
There's a lot of trust in the Apache name, and we want to maintain that
That trust is what makes people use apache software.
It was earned the hard way, and must be protected at any cost.
Because it is inpractical for the ASF to independently check all
software published on apache.org, it has to delegate that responsibilty
to institutions like pmc@top-level-project.apache.org.
They in turn delegate to persons and/or sub-projects, etc.
It is clear how the ASF is
organized.
However, to me, it is unclear how this delegation is formalized.
How do you prove that some person, who signed a piece of apache
software, has the (delegated) trust of the board of the ASF?
If some directory contains a KEYS file, are all persons mentioned
in the KEYS file trusted to publish only good, trustworthy stuff?
Note that the
new committers guide recommends that every committer should add
him/her-self to the proper KEYS file. That is a low threshold.
Earlier discussions showed that some people view the KEYS files
as nothing more than a convenience for the downloaders; in
other words a key in a KEYS file implies nothing about the
trust that the ASF has in the key owner as an apache publisher.
In this model, the ASF is invisible and the downloader has to
derive trust from
- his/her trust in the key-owner as an individual ;
for most downloaders this is useless because they
only trust the ASF, not individuals
- the fact that the software is in apache.org/dist/ ;
in this case the signature and the signer are not relevant
I can't answer this question.
Scrap the KEYS infrastructure, or generate it.
Create a structure where :
- the ASF authorises projects
- projects authorise release managers
- projects authorise sub projects
- comitters (esp release managers) specify their key(s)
The goal is to authorise objects in a tree ;
if we treat hard links and symlinks to files as
copies, a filesystem is a tree.
There are two responsibilities:
- authoriser: authorises release managers and/or authorisers for subprojects
- release manager: inserts objects in a subtree
So, let's have signed AUTH files containing this info:
For the ASF, it works like this :
- the ASF
- has a ASF key which must be cross signed by the current
chairman, president, whatever
- has a ROOT file
- indicating which users, typically officers,
can sign the ASF's root AUTH file
- signed by the ASF key
- has a root AUTH file
- indicating which users, typically the pmc ASF members,
can sign the project's AUTH file
- signed by someone authorised in ROOT
- every project
- has a AUTH file
- indicating its release managers and/or the authorisers of its subprojects
- signed by someone in the root AUTH file
- every subproject
- has a AUTH file
- indicating its release managers and/or the authorisers
of its subsubprojects
- signed by someone in the project's AUTH file
- every committer
- has a file $HOME/.pgpkey that contains his/her public key
- is asked for at least (at most :-) one pgp key on the application form ;
this key should be on the key servers etc ;
passwords, certs etc are sent to them, crypted with that key ;
release managers should have keys in the PGP strong set
Note:
- with AUTH files, for every package in /dist/, we can present a downloader with
a proof that the publisher of the package is authorised by the ASF
- instead of refering to authorisers and release managers
by login, we could refer to key_ids in AUTH files.
This is more straight forward, but also more error prone.
It has to be login and key_id ; when an account is broken,
it is easy to add a key to ~user/.pgpkey.
- if we can use keyman to implement this, fine.
- we can check the $HOME/.pgpkey for doubles and other curiosa
- for java-repository, we can allow everybody to be a release manager
with "RM *", brr.
- we lose the KEYS files, but we can generate them if we want them
Example: apache.org/dist/AUTH (root AUTH)
- based on current owners of TLP/KEYS
- the stable situation would be : the members on the project's pmc
AU ant bodewig ...
AU apr pquerna ...
AU avalon leosutic ...
AU cocoon cziegeler ...
AU directory akarasulu ...
AU excalibur leif ...
AU forrest crossley ...
AU httpd fielding ...
AU jakarta rdonkin foo bar # <-----------------------
AU james noel ...
AU lenya gregor ...
AU logging carnold ...
AU maven jvanzyl ...
AU myfaces schof ...
AU perl cholet ...
AU spamassassin jm ...
AU struts martinc ...
AU tcl patthoyts ...
AU xmlbeans radup ...
Example: apache.org/dist/jakarta/AUTH
- based on current owners of jakarta/*/KEYS
- in this example, jakarta/AUTH must be signed by users rdonkin, foo or bar
AU bcel rdonkin
AU cactus vmassol felipeal
AU ecs rdonkin
AU hivemind hlship
AU jetspeed morciuch taylor
AU jmeter mstover1 sebb
AU log4j ceki
AU lucene ehatcher
AU oro dfs
AU regexp vgritsenko
AU slide rdonkin
AU struts martinc
AU taglibs felipeal
AU tapestry ehatcher
AU tomcat-3 rdonkin
AU tomcat-4 remm
AU tomcat-5 yoavs
AU tomcat-connectors mturk
AU turbine henning
AU velocity-tools nbubna
AU velocity rdonkin
