-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Ben,
>I'm proposing that we have a project key which will be held by the
>CollabNet folks for the time being.
In my opinion, a project key is not a good idea. You should be able to
do this kind of theing using the individual authorities of your own
project members.
>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.
I suggest that the right thing to do is set up a web of trust with GPG
for all of your committers. Then you don't need to do anything with
individual md5sum values.
>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).
Fine.
>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.
Fine.
>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.
Building a highly interconnected web of trust is a good idea in any
case.
>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.
This is a poor idea. Just have the three or four signatures that verify
and are in the list of acceptable voting members and post the release
with the signatures. There is no need to have any other signatures out
there.
>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.
If you feel that the collabnet people must be involved. Have them sign
each of the public keys of the committers. This widens the web of
trust... assuming that someone trusts the collabnet signature in the
first place.
>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.
If they see four signatures that all verify and are cross-signed keys
known to be in the committers list, wouldn't that be good enough too?
>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.
Do this now and don't try to mess around with intermediate security
measures.
>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.
I think you need to arrange to generate your own keys now and begin to
use them and throw some key signing parties sooner than later.
Enjoy!
-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAc074DsmuPPFOO2cRAhQ3AJ9YzYLvvcG4ut4raXHFSlabGPTiwQCeLo9Z
AQYTOF09hE9/QRaOFQ/DXV0=
=pVln
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 02:44:53 2004