Mark Phippard wrote on Fri, Aug 10, 2012 at 09:30:01 -0400: > On Fri, Aug 10, 2012 at 9:06 AM, Philip Martin > <[email protected]> wrote: > > Justin Erenkrantz <[email protected]> writes: > > > >> On Wed, Aug 8, 2012 at 1:40 PM, Philip Martin > >> <[email protected]> wrote: > >>> Subversion 1.7.6 tarballs are now available for testing/signing by > >>> committers. To obtain them please check out a working copy from > >>> https://dist.apache.org/repos/dist/dev/subversion > >> > >> +1 for release. > >> > >> Tested on Mac OS X 10.7.4. > >> > >> All tests pass (even the one that C-Mike pointed out failed for him). > >> > >> BTW, I used the release.py script...which signed all of the release > >> files. *shrug* > > > > You didn't have to commit all the files! You can also sign the files > > manually without using release.py. > > > > I signed all the files as release manager but while I looked at the zip > > file I didn't build/test it. When signing releases in the past I signed > > only the files I tested. I suppose we should extend release.py to > > support signing a subset. > > I have sometimes wondered why we do not all sign all of the files.
The idea is that a hypothetical malicious release manager could create tar.gz and tar.bz2 correctly but a malicious .zip file. We could write a release.py subcommand that compares the tar.gz/tar.bz2/zip to each other (and to the tag in svn.a.o). Then people can run release.py intercompare-tarballs && release.py sign-tarballs > Purely from a gpg trust perspective isn't more signatures a good > thing? As long as we are still properly counting the +1's we get for > Windows/Unix it does not seem like it hurts anything to have more > signatures on the files. > > I could be wrong of course, I only kind of understand the intent of > gpg signatures. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/
