[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Security flaw caused by RC sigs [was: Release policy question]

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2006-02-03 04:11:31 CET

On Thu, 2006-02-02 at 18:09 -0800, Christian Stork wrote:
> > I don't understand why what I said applies any differently to -rc
> > releases than to regular ones.
>
> I assumed that you made the distinction between
>
> testing tarballs, which contain the final release version string (eg
> 1.4.0)
>
> versus
>
> RC tarballs, which contain a non-final version string (eg
> 1.4.0-rc3).
>
> Maybe I read too much into that. It seems by "testing tarballs" you
> meant the RC tarballs. Sorry for the confusion then.

Uh, no...

We release successful rc tarballs, each signed, containing bugfixes
relative to the previous release candidate discovered during testing.
We test each rc tarball among the developers, signing it as it is
tested, as a measure of quality control before it is released. If we
reuse an rc number because of a broken tarball preparation (not that we
would have much reason to do so), then an attacker could substitute the
broken rc tarball, but the attacker could not substitute a previous
version (since the tarball contains the version number) or a modified
version.

Similarly, we release actual releases, each signed, containing bugfixes
or (for x.y.0 releases) new features relative to the past release. We
test each release tarball among the developers, siging it as it is
tested, as a measure of quality control before it is released. If we
reuse a release number because of a broken tarball preparation, then the
same considerations apply.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 3 04:12:55 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.