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

Re: Release policy question

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2006-02-03 06:22:56 CET

On 02 Feb 2006 12:25:35 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> This is unrelated to our numbering strategy.

Not quite true.

> If release X is blessed by sufficient signers, and then later
> discovered to have a security flaw, then those who installed release X
> need to upgrade to a new, different release with its own sigs. That's
> true no matter what the names of the releases are.

There would be no way to know that release X and Y are different if
they both report themselves as the same version.

> I don't understand exactly what Evil Hacker would do to make Good
> Company believe that the x.y.0-rc1 sigs apply to x.y.0. The two
> tarballs are different, so the sigs will be different.

In your scenario, the tarball would internally represent itself as
being x.y.0. Because you're signing the content as a final release,
the content itself must be final. (You can't have the tarball report
itself as an rc because it'd be getting signed as a final release.)

I'm really, really against reusing version numbers in any form. All
it does is lead to confusion if someone pulls that tarball down -
there'd be *no* way for Subversion to tell that the 2.4.6 tarball
released on 1/31/2007 is different from the 2.4.6 tarball released on
2/7/2007.

httpd has hit this problem a few times in the past due to sloppiness
on our parts. It's a nightmare that makes everyone wish they had just
burned the version number in the first place. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 3 06:23:52 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.