Mark Phippard wrote on Fri, Aug 10, 2012 at 09:30:01 -0400:
> On Fri, Aug 10, 2012 at 9:06 AM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
> > Justin Erenkrantz <justin_at_erenkrantz.com> writes:
> >
> >> On Wed, Aug 8, 2012 at 1:40 PM, Philip Martin
> >> <philip.martin_at_wandisco.com> 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/
Received on 2012-08-11 20:57:51 CEST