+1, some comments below:
Ben Reser <ben@reser.org> writes:
> 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.
And phone is fine too :-).
> 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).
Indeed, the testing part is entirely independent of the
verification/signing part. (Technically it doesn't even need to be
part of this proposal, therefore.)
> 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.
Note that you can verify (say) the gzip package, then unpack the bzip2
and do a 'diff -r' between the two trees. If there's no difference,
you can sign the bzip2 package as well.
> 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.
Exactly. I'd like to stress this point, as it's important:
The purpose of the project key is so that, once someone has done the
work of verifying that they trust *that key*, they never have to do
that work again -- even though the set of people involved in releasing
may go through 100% turnover eventually (thus causing 100% turnover in
the personal keys that sign the releases).
> 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.
Yup.
> 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.
I think we can get a web of trust for 1.0.2 pretty easily. We've got
four developers in the same room over here, plus we can all easily
verify (via personal information) with Sander Striker, Greg Stein,
Daniel Rall, and others. It shouldn't be hard to spread such a broad
core out to include a lot of people pretty fast.
If the above proposal looks overly complex to anyone, remember that
most of the complexity remains even if you take out the group key
part. In other words, signing releases in a careful and useful way
has some inherent complexities -- the group key is only a small part
of that. And we *do* want to sign them: if you've ever been hacked (I
have) you'll understand the urge to verify before installing new
server software.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 21:20:40 2004