Seeing as not very many people have responded to the earlier thread and
my embedded proposal, I'm posting a separate email clearly titled...
I'm proposing that we have a project key which will be held by the
CollabNet folks for the time being. However, the project keys signature
would not be the only signature on a release. Releases would happen as
follows:
The Release Manager will generate a tarball and sign it with their own
key. This will be posted to some location that is private to the
committers. Along with the tarball of course will be an ASCII armored
GPG signature and md5sum. The MD5 sum will also be mailed to the
committers via email. The RM will also make themselves available on IRC
in order to verify the md5sum.
Interested committers will download the tarball(s), verify the tarball
against the GPG signature (if they have a trust path) and/or md5sum (if
they don't have a trust path or are just truly paranoid). They will
then test the package (extract it, build it, make check it, though to
what degree is up to the committer).
Once they are +1 on the using this as the package for the release they
will generate an ASCII armored GPG signature of the package. (Note they
may need to go through this process for multiple packages, we have a
gzip and bzip2 package and plans for a zip package. However, nobody
will have to sign all the packages, the signatures can differ). They
will send this signature back to the RM. Who will check that it is a
good signature and then concatenate it to the signature file for the
package.
In order for the RM to verify the signature it will be useful for this
person to build a trust path to everyone that wants to participate in
the process. We can initially bootstrap that chain off Debian or Apache
developers who are well connected.
Once we've received a certain number of signatures on a package (I'm
think 3 at a minimum and based upon participation possibly bumping that
up.) the package will be downloaded by the CollabNet guys who will once
again verify the signatures (again they need trust path's). When
they're satisfied that the release signatures are good they will sign
the package with the project key and append it to the signature file.
In the end if we require 3 signatures we'll end up with at least 4
signatures on the package.
Why have the project key? Because many people who do not participate in
the web of trust may wish to use GPG to verify our packages. They can
verify the signature much as they would an md5sum (checking multiple
sources). Once they've done this, unless our key changes they'll be
able to verify releases without going through this process again.
However, having individual signatures, gives those wanting to use the
web of trust the ability to do so, helps in our release process of
giving a clear list of who has signed off on a release (pun intended)
and makes the signature on the package much harder to forge. People
knowing that we always have 4 or more signatures on our packages will be
suspicious of any single signature. So now we wouldn't have a single
point of failure.
Eventually, we'll be able to build a web of trust so that those
interested should be able to verify every signature on the package and
thereby increasing our overall security.
I'm not sure when we can start doing this. We need to get web of trust
issues worked out as best as we can with individual developers. So
I'm not thinking this is a 1.0.2 time frame thing. But maybe 1.0.3 or
1.1.0 thing.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 20:47:28 2004