You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/12/31 02:01:03 UTC
Release policy question (was: Re: 1.3.0 tarballs up for testing/signing (again))
David Anderson <da...@calixo.net> writes:
> After a slight mixup in the distribution scripts, the 1.3.0 tarballs have been
> rerolled. The new versions, rolled from r17949, are now available (as of 30
> December 15:00 GMT).
>
> http://lolut.utbm.info/pub/subversion-1.3.0/final/
Policy question:
In the past, we had a policy that once a tarball is mentioned in a
public forum, that name is used up, and any new tarball must have a
new name. But now, two different tarballs have been released into the
world under the name "1.3.0". Is this something we discussed and
decided we could live with?
(Yes, the old policy meant that if there was some problem with 1.3.0,
then the first "real" 1.3.x release would be 1.3.1. One purpose of
the "-rcX" releases preceding the first ".0" release in a series is to
minimize the chance of this happening... but if it did happen, it
wasn't supposed to be a disaster. In the old policy, maintaining
unambiguous uniqueness was considered most important.)
I don't see anything in www/hacking.html or notes/releases.txt to
resolve my question. I do recall some discussions in the semi-recent
past about this, so maybe we decided to loosen the policy (David's use
of "r17949" to disambiguate is an example of why this can work).
If we are all agreed that the new policy is
"We will try as hard as we can, through the use of RCs, to avoid
releasing different tarballs under the same name. But we may
still allow it to happen as long as the tarball of that name is
still in testing/signing and has not been officially 'blessed'."
then I (or someone) can update hacking.html accordingly.
Thoughts?
David: I probably won't be able to test the new tarballs before the
New Year, sorry. For what it's worth, the previous 1.3.0 release
(r17947) did pass the 6-way tests for me. C'est la vie :-).
-Karl
> Again, no end-user distribution and all that. This tarball is identical to the
> previous, with two exceptions:
> - A fix to dist.sh that was in trunk has been merged into the 1.3.x line.
> This fix makes svn_version.h change before the swig bindings are compiled. So
> now the version numbers should be correct in the pre-generated SWIG code.
> - The modification of the dist.sh script means the SWIG binding code has
> changed. Cosmetic only, as only the version numbers exported to SWIG have changed.
>
> Other than that, this tarball is the same as rc7 and as the previous "final"
> tarball.
>
> Committers, please test and submit your signatures, again.
>
> - Dave, aka. "The Two Tarballs"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by kf...@collab.net.
Max Bowsher <ma...@ukf.net> writes:
> The issue here, is balancing the technical correctness of our version
> numbers with the public perception of them.
Agreed.
> Having the first real release of 1.3.x being called 1.3.1 would have
> been odd. Perhaps what we should have done is to have called the reroll
> "1.3.0a" - similar to what Debian did with a tiny bug in sarge, which
> resulted in "Debian 3.1r0" followed by "Debian 3.1r0a".
I think people would find that more confusing than just re-releasing
"1.3.0" (I know I would, anyway).
I'm okay with Justin's and Erik's policy suggestion, already posted in
response to my mail. I'll wait a bit to hear more feedback, then
modify hacking.html accordingly.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
kfogel@collab.net wrote:
> David Anderson <da...@calixo.net> writes:
>
>>After a slight mixup in the distribution scripts, the 1.3.0 tarballs have been
>>rerolled. The new versions, rolled from r17949, are now available (as of 30
>>December 15:00 GMT).
>>
>>http://lolut.utbm.info/pub/subversion-1.3.0/final/
>
>
> Policy question:
>
> In the past, we had a policy that once a tarball is mentioned in a
> public forum, that name is used up, and any new tarball must have a
> new name. But now, two different tarballs have been released into the
> world under the name "1.3.0". Is this something we discussed and
> decided we could live with?
>
> (Yes, the old policy meant that if there was some problem with 1.3.0,
> then the first "real" 1.3.x release would be 1.3.1. One purpose of
> the "-rcX" releases preceding the first ".0" release in a series is to
> minimize the chance of this happening... but if it did happen, it
> wasn't supposed to be a disaster. In the old policy, maintaining
> unambiguous uniqueness was considered most important.)
>
> I don't see anything in www/hacking.html or notes/releases.txt to
> resolve my question. I do recall some discussions in the semi-recent
> past about this, so maybe we decided to loosen the policy (David's use
> of "r17949" to disambiguate is an example of why this can work).
>
> If we are all agreed that the new policy is
>
> "We will try as hard as we can, through the use of RCs, to avoid
> releasing different tarballs under the same name. But we may
> still allow it to happen as long as the tarball of that name is
> still in testing/signing and has not been officially 'blessed'."
>
> then I (or someone) can update hacking.html accordingly.
>
> Thoughts?
The issue here, is balancing the technical correctness of our version
numbers with the public perception of them.
Having the first real release of 1.3.x being called 1.3.1 would have
been odd. Perhaps what we should have done is to have called the reroll
"1.3.0a" - similar to what Debian did with a tiny bug in sarge, which
resulted in "Debian 3.1r0" followed by "Debian 3.1r0a".
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDuVkefFNSmcDyxYARAmTyAJ9VtQOTLFIYQjQQy+a78dH2fbWXMgCg0ubC
5BSScnfYH3KqtqBcQrKG8rg=
=NIkr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 31 Jan 2006, Karl Fogel wrote:
> Daniel Rall <dl...@collab.net> writes:
> > I'm saying it's simplest to call the new tarball x.y.(z + 1), if the
> > previous tarball was named x.y.z. I'm advocating that approach even
> > when nothing meaningful in the source code has changed between
> > tarballs. I believe we've done this in the past when a tarball has
> > been DOA.
>
> Yes, that's also what Greg is advocating. I'm +1 on it too.
>
> Sanity check: you also mean that if we put out X.Y.Z-rc3, and five
> minutes later we discover a trivial typo in a README, and reroll a new
> tarball before *anyone* has signed the RC, that we will still call the
> new tarball X.Y.Z-rc4, right?
>
> IOW, this applies to RCs as well as non-RCs.
I'm fine with that. The alternative would be to do away with RCs
entirely, but that might be oversimplifying the problem (e.g. it
removes the implicit "GA"-ness of our non-RC releases).
--
Daniel Rall
Re: Release policy question
Posted by kf...@collab.net.
Daniel Rall <dl...@collab.net> writes:
> I'm saying it's simplest to call the new tarball x.y.(z + 1), if the
> previous tarball was named x.y.z. I'm advocating that approach even
> when nothing meaningful in the source code has changed between
> tarballs. I believe we've done this in the past when a tarball has
> been DOA.
Yes, that's also what Greg is advocating. I'm +1 on it too.
Sanity check: you also mean that if we put out X.Y.Z-rc3, and five
minutes later we discover a trivial typo in a README, and reroll a new
tarball before *anyone* has signed the RC, that we will still call the
new tarball X.Y.Z-rc4, right?
IOW, this applies to RCs as well as non-RCs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Sigfred Håversen <bs...@mumak.com>.
Daniel Rall wrote:
> On Tue, 31 Jan 2006, Karl Fogel wrote:
>
>> Daniel Rall <dl...@collab.net> writes:
>>> I too prefer Greg's suggested strategy. It's simpler, and results in
>>> less possibility for errors when referring to a release, since it
>>> needn't be qualified with "rcX".
>> Hmm. Somebody is misunderstanding something here, but I'm not sure if
>> it's you, me, or Greg, or some combination therewhom :-).
>>
>> IIUC, Greg wasn't proposing getting rid of the "-rcX" tarballs. He
>> was just saying let's never issue two tarballs with different content
>> but the same name (something we currently can do, and have done,
>> albeit in very limited circumstances).
>
> I'm saying it's simplest to call the new tarball x.y.(z + 1), if the
> previous tarball was named x.y.z. I'm advocating that approach even
> when nothing meaningful in the source code has changed between
> tarballs. I believe we've done this in the past when a tarball has
> been DOA.
You could extend this to any change, including a reroll of the tarball. A MD5
sum of the tarball is commonly encoded into a port, and any changes in this
will stop the build.
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 31 Jan 2006, Daniel Rall wrote:
> On Tue, 31 Jan 2006, Karl Fogel wrote:
>
> > Daniel Rall <dl...@collab.net> writes:
> > > I too prefer Greg's suggested strategy. It's simpler, and results in
> > > less possibility for errors when referring to a release, since it
> > > needn't be qualified with "rcX".
> >
> > Hmm. Somebody is misunderstanding something here, but I'm not sure if
> > it's you, me, or Greg, or some combination therewhom :-).
> >
> > IIUC, Greg wasn't proposing getting rid of the "-rcX" tarballs. He
> > was just saying let's never issue two tarballs with different content
> > but the same name (something we currently can do, and have done,
> > albeit in very limited circumstances).
>
> I'm saying it's simplest to call the new tarball x.y.(z + 1), if the
> previous tarball was named x.y.z. I'm advocating that approach even
> when nothing meaningful in the source code has changed between
> tarballs. I believe we've done this in the past when a tarball has
> been DOA.
>
+1. I like a simple policy. Hopefully such trivial packaging errors
should be rare enough that this is not a big deal.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Blair Zajac <bl...@orcaware.com>.
On Feb 2, 2006, at 10:52 AM, kfogel@collab.net wrote:
> "Erik Huelsmann" <e....@gmx.net> writes:
>> I'm not at all for burning version numbers. I have advocated
>> using .0a for
>> the second release. This has hit some emotional barriers back
>> when we were
>> about to release 1.3.0, as well as it did yesterday on IRC when I
>> re-raised
>> the issue.
>>
>> Though .0a may be meaningless to users, it'd be apparent to
>> everybody (I'd
>> guess) that .0c is the version to use when you have to choose
>> from .0a, .0b
>> and .0c...
>
> Please, not the "a", "b", "c" thing. It doesn't solve the problems
> Greg pointed out: people expect a "clean" number for the first
> release, and if they don't see it, some of them will wonder why
> Conversely, conservative admins may see a "c" release and think it
> represents something significantly more mature than the "a" or ""
> release and upgrade to it, when that's actually not in accord with
> their risk-averse upgrade policy.
>
> We need to face the fact that there are disadvantages to all choices
> here, but also that none of the disadvantages are very severe.
>
> I'm +1 on the "always make a new number" option and on the "it's okay
> to re-use a number in certain rare circumstances" option, but -0 on
> this "a"/"b"/"c" thing. I've not found it particularly helpful when
> I've encountered it in other software.
Agreed. I used to do releases of Orca with that and people would
think that the a=alpha, b=beta, but is not what you want.
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by kf...@collab.net.
"Erik Huelsmann" <e....@gmx.net> writes:
> I'm not at all for burning version numbers. I have advocated using .0a for
> the second release. This has hit some emotional barriers back when we were
> about to release 1.3.0, as well as it did yesterday on IRC when I re-raised
> the issue.
>
> Though .0a may be meaningless to users, it'd be apparent to everybody (I'd
> guess) that .0c is the version to use when you have to choose from .0a, .0b
> and .0c...
Please, not the "a", "b", "c" thing. It doesn't solve the problems
Greg pointed out: people expect a "clean" number for the first
release, and if they don't see it, some of them will wonder why
Conversely, conservative admins may see a "c" release and think it
represents something significantly more mature than the "a" or ""
release and upgrade to it, when that's actually not in accord with
their risk-averse upgrade policy.
We need to face the fact that there are disadvantages to all choices
here, but also that none of the disadvantages are very severe.
I'm +1 on the "always make a new number" option and on the "it's okay
to re-use a number in certain rare circumstances" option, but -0 on
this "a"/"b"/"c" thing. I've not found it particularly helpful when
I've encountered it in other software.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Erik Huelsmann <e....@gmx.net>.
> On Tue, 2006-01-31 at 14:37 -0800, Garrett Rooney wrote:
> > > > No, thanks to the RCs that catch most of the problems. It would
> have
> > > > been 1.3.1, though, instead of 1.3.0 (if I recall the series of
> events
> > > > correctly).
> > >
> > > FWIW, isn't that what httpd does?
> >
> > I'm not positive about HTTPD, but APR does something like that. We've
> > burned through two version numbers for the current APR release due to
> > issues that were not caught until the tarballs were out there being
> > tested. Not that it's a big deal though, version numbers are cheap
> > ;-)
>
> I think this is an error. Version numbers mean something to users, so
> they aren't *that* cheap. Having the first 1.3 release of Subversion be
> 1.3.1 would have been confusing to some people, and falsely reassuring
> to others (who avoid .0 releases out of conservatism).
>
> So, I'm not 100% happy with a process that causes us to burn version
> numbers when a tarball fails testing. In the past, I've advocated
> naming the tarball something random when we post it, but apparently that
> has technical issues.
I'm not at all for burning version numbers. I have advocated using .0a for
the second release. This has hit some emotional barriers back when we were
about to release 1.3.0, as well as it did yesterday on IRC when I re-raised
the issue.
Though .0a may be meaningless to users, it'd be apparent to everybody (I'd
guess) that .0c is the version to use when you have to choose from .0a, .0b
and .0c...
Those are my 0.02 euros.
Bye,
Erik.
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Peter Samuelson <pe...@p12n.org>.
[Justin Erenkrantz]
> On 02 Feb 2006 12:25:35 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> > 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 think the Evil Hacker scenario is a strawman. I don't see anyone
reusing a version number when the difference is something as
interesting as a security fix. We're talking about rerolling a tarball
because something procedural was done wrong. (That should be rare in
any case, since the procedures should be pretty much scripted.) Not
actual code changes.
Re: Release policy question
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 02 Feb 2006 12:25:35 -0600, kfogel@collab.net <kf...@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
Re: Security flaw caused by RC sigs [was: Release policy question]
Posted by Greg Hudson <gh...@MIT.EDU>.
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
Re: Security flaw caused by RC sigs [was: Release policy question]
Posted by Christian Stork <cs...@ics.uci.edu>.
On Thu, Feb 02, 2006 at 08:56:48PM -0500, Greg Hudson wrote:
> On Thu, 2006-02-02 at 14:45 -0800, Christian Stork wrote:
> > > If we've reused the version number from a testing tarball, that would be
> > > a problem, but we've never considered reusing a version number because
> > > of a security flaw, only because of a packaging failure which caused
> > > build problems or the like. There is no security issue with
> > > substituting such a broken x.y.0 tarball for the real one.
> > OK, that makes sense then wrt to the testing tarballs (and should be
> > enshrined in the release policiy!).
> > But what's the point of the RC signatures then? For secure communication
> > among the developers?? Or are you just "practicing" the release process?
> 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.
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Security flaw caused by RC sigs [was: Release policy question]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2006-02-02 at 14:45 -0800, Christian Stork wrote:
> > If we've reused the version number from a testing tarball, that would be
> > a problem, but we've never considered reusing a version number because
> > of a security flaw, only because of a packaging failure which caused
> > build problems or the like. There is no security issue with
> > substituting such a broken x.y.0 tarball for the real one.
>
> OK, that makes sense then wrt to the testing tarballs (and should be
> enshrined in the release policiy!).
>
> But what's the point of the RC signatures then? For secure communication
> among the developers?? Or are you just "practicing" the release process?
I don't understand why what I said applies any differently to -rc
releases than to regular ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Security flaw caused by RC sigs [was: Release policy question]
Posted by Christian Stork <cs...@ics.uci.edu>.
On Thu, Feb 02, 2006 at 04:49:24PM -0500, Greg Hudson wrote:
> On Thu, 2006-02-02 at 12:45 -0800, Christian Stork wrote:
> > On Thu, Feb 02, 2006 at 12:25:35PM -0600, kfogel@collab.net wrote:
> > Evil Hacker doesn't! She installs x.y.0-rc1 under the name x.y.0 and
> > gives Good Company the sigs of the RC. Then Good Company verifies the
> > sigs using the public keys of some committers which it received at some
> > key signing party.
> The tarball does contain the version number inside, so Good Company will
> presumably notice that the tarball named x.y.0 actually contains
> x.y.0-rc1.
> If we've reused the version number from a testing tarball, that would be
> a problem, but we've never considered reusing a version number because
> of a security flaw, only because of a packaging failure which caused
> build problems or the like. There is no security issue with
> substituting such a broken x.y.0 tarball for the real one.
OK, that makes sense then wrt to the testing tarballs (and should be
enshrined in the release policiy!).
But what's the point of the RC signatures then? For secure communication
among the developers?? Or are you just "practicing" the release process?
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Security flaw caused by RC sigs [was: Release policy question]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2006-02-02 at 12:45 -0800, Christian Stork wrote:
> On Thu, Feb 02, 2006 at 12:25:35PM -0600, kfogel@collab.net wrote:
> Evil Hacker doesn't! She installs x.y.0-rc1 under the name x.y.0 and
> gives Good Company the sigs of the RC. Then Good Company verifies the
> sigs using the public keys of some committers which it received at some
> key signing party.
The tarball does contain the version number inside, so Good Company will
presumably notice that the tarball named x.y.0 actually contains
x.y.0-rc1.
If we've reused the version number from a testing tarball, that would be
a problem, but we've never considered reusing a version number because
of a security flaw, only because of a packaging failure which caused
build problems or the like. There is no security issue with
substituting such a broken x.y.0 tarball for the real one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Security flaw caused by RC sigs [was: Release policy question]
Posted by Christian Stork <cs...@ics.uci.edu>.
On Thu, Feb 02, 2006 at 12:25:35PM -0600, kfogel@collab.net wrote:
> Christian Stork <cs...@ics.uci.edu> writes:
> > Hmm, then you guys might have a problem:
> > - svn x.y.0rc1 was signed by all relevant people but not released due to
> > a security flaw discovered in the last minute.
> > - svn x.y.0 released without security flaw.
> > Evil Hacker can now reuse the x.y.0rc1 sigs to make Good Company believe
> > it installed svn x.y.0 even though they installed the flawed x.y.0rc1
> > but they feel secure since they checked all relevant sigs.
> > This would be a sort of replay attack, I guess.
> This is unrelated to our numbering strategy.
Sorry, I should have changed the subject earlier.
> 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.
The sigs should clearly identify what they mean. Maybe you
misunderstood my argument. See below.
> 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.
Evil Hacker doesn't! She installs x.y.0-rc1 under the name x.y.0 and
gives Good Company the sigs of the RC. Then Good Company verifies the
sigs using the public keys of some committers which it received at some
key signing party.
Now you might say that Good Company should also check the publicly
available MD5 sum of the finally released tarball. Well, the problem is
that this MD5 is not signed (iiuc) and is communicated over insecure
channels. For example, Evil Hacker could have a simple filter in the
company firewall that does nothing else but replace the RC's MD5 digest
with the release's MD5 digest. Point being, this information can't be
trusted.
Of course, the subversion project could take the position that it's good
enough the allow this attack to happen for several release candidates,
but, thinking abou it, a little change in the release process could get
rid of this kind of attack.
1. RM sends out RCs
2. Committers test and approve or disapprove (go back to 1.) until
there's an RC that has enough approvals (no sigs required yet if you
trust email somewhat!)
3. The moment that RC is blessed, the RM and Committers sign strings like
this
"subversion-x.y.z.tar.gz <MD5-digest-of-subversion-x.y.z.tar.gz>"
4. From that point on (ie as soon as there exists one relevant sig of
that form) the x.y.z version is used up.
I hope that's clearer.
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by kf...@collab.net.
Christian Stork <cs...@ics.uci.edu> writes:
> Hmm, then you guys might have a problem:
>
> - svn x.y.0rc1 was signed by all relevant people but not released due to
> a security flaw discovered in the last minute.
> - svn x.y.0 released without security flaw.
>
> Evil Hacker can now reuse the x.y.0rc1 sigs to make Good Company believe
> it installed svn x.y.0 even though they installed the flawed x.y.0rc1
> but they feel secure since they checked all relevant sigs.
>
> This would be a sort of replay attack, I guess.
This is unrelated to our numbering strategy.
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.
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.
?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Christian Stork <cs...@ics.uci.edu>.
On Thu, Feb 02, 2006 at 07:29:13PM +0100, Sander Striker wrote:
...
> AFAIK it is. You sign the content, not the name.
Hmm, then you guys might have a problem:
- svn x.y.0rc1 was signed by all relevant people but not released due to
a security flaw discovered in the last minute.
- svn x.y.0 released without security flaw.
Evil Hacker can now reuse the x.y.0rc1 sigs to make Good Company believe
it installed svn x.y.0 even though they installed the flawed x.y.0rc1
but they feel secure since they checked all relevant sigs.
This would be a sort of replay attack, I guess.
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
> AFAIK it is. You sign the content, not the name.
Sander is right. So we can post
notareleasedtarballofsubversion-1.4.0.tar.gz, have testers sign that,
then just rename the tarball and use the sigs. No overhead for anyone
except the RM.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Sander Striker <st...@apache.org>.
Branko Čibej wrote:
> Greg Hudson wrote:
>
>> On Tue, 2006-01-31 at 14:37 -0800, Garrett Rooney wrote:
>>
>>
>>>>> No, thanks to the RCs that catch most of the problems. It would have
>>>>> been 1.3.1, though, instead of 1.3.0 (if I recall the series of events
>>>>> correctly).
>>>>>
>>>>
>>>> FWIW, isn't that what httpd does?
>>>>
>>>
>>> I'm not positive about HTTPD, but APR does something like that. We've
>>> burned through two version numbers for the current APR release due to
>>> issues that were not caught until the tarballs were out there being
>>> tested. Not that it's a big deal though, version numbers are cheap
>>> ;-)
>>>
>>
>>
>> I think this is an error. Version numbers mean something to users, so
>> they aren't *that* cheap. Having the first 1.3 release of Subversion be
>> 1.3.1 would have been confusing to some people, and falsely reassuring
>> to others (who avoid .0 releases out of conservatism).
>>
>> So, I'm not 100% happy with a process that causes us to burn version
>> numbers when a tarball fails testing. In the past, I've advocated
>> naming the tarball something random when we post it, but apparently that
>> has technical issues.
>>
>
> IIRC the only issue is that if you sign such a randomly-named file, the
> signature isn't valid for the correctly-named file. Well, people whose
> signatures count can rename the tarball locally before signing it.
AFAIK it is. You sign the content, not the name.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by David James <dj...@collab.net>.
On 2/2/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > Re Greg's comments: I'm not 100% happy either with a method that can
> > result in the first release in a series being something other than
> > ".0". But I'm not 100% happy with the alternatives either, and at
> > least we can always put something in the release notes explaining what
> > happened, so those who bother to read the notes will not be confused.
>
>
> It's hard to make a judgement call here, because we're weighing
> "complex for svn developers" vs. "confusing for users".
>
> Is the extra release-complexity imposed on ~15 active developers worth
> the tradeoff of preventing user-confusion over tarball names? It
> sounds like you think it's not worth it. I'm sort of thinking it is.
> Hm.
+1. I'd be happy to rename the tarball before signing, especially if
it would save us from burning version numbers unnecessarily.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Ben Collins-Sussman <su...@red-bean.com>.
> Re Greg's comments: I'm not 100% happy either with a method that can
> result in the first release in a series being something other than
> ".0". But I'm not 100% happy with the alternatives either, and at
> least we can always put something in the release notes explaining what
> happened, so those who bother to read the notes will not be confused.
It's hard to make a judgement call here, because we're weighing
"complex for svn developers" vs. "confusing for users".
Is the extra release-complexity imposed on ~15 active developers worth
the tradeoff of preventing user-confusion over tarball names? It
sounds like you think it's not worth it. I'm sort of thinking it is.
Hm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 2 Feb 2006, Greg Hudson wrote:
> On Thu, 2006-02-02 at 10:22 -0600, kfogel@collab.net wrote:
> > > IIRC the only issue is that if you sign such a randomly-named file,
> > > the signature isn't valid for the correctly-named file. Well, people
> > > whose signatures count can rename the tarball locally before signing
> > > it.
>
> > I think that would get us into a degree of complexity we don't want.
>
> > Simplicity is: you get handed an object, you test it, sign it, and
> > post your signature.
>
> > Complexity is: anything more than that :-).
>
> Well, it's a little bit of complexity for testers, vs. a little bit of
> complexity for users. There are a lot more users than testers.
>
Agreed. I test the tarball using a script anyway (which includes
generating .gz from .bz2 and signing), so that little extra complexity
doesn't seem like a problem to me. This sounds like a good solution to
me.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2006-02-02 at 10:22 -0600, kfogel@collab.net wrote:
> > IIRC the only issue is that if you sign such a randomly-named file,
> > the signature isn't valid for the correctly-named file. Well, people
> > whose signatures count can rename the tarball locally before signing
> > it.
> I think that would get us into a degree of complexity we don't want.
> Simplicity is: you get handed an object, you test it, sign it, and
> post your signature.
> Complexity is: anything more than that :-).
Well, it's a little bit of complexity for testers, vs. a little bit of
complexity for users. There are a lot more users than testers.
> Re Greg's comments: I'm not 100% happy either with a method that can
> result in the first release in a series being something other than
> ".0". But I'm not 100% happy with the alternatives either, and at
> least we can always put something in the release notes explaining what
> happened, so those who bother to read the notes will not be confused.
We can post whatever we want, but some substantial fraction of people
won't see it before they jump to conclusions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> > So, I'm not 100% happy with a process that causes us to burn version
> > numbers when a tarball fails testing. In the past, I've advocated
> > naming the tarball something random when we post it, but apparently that
> > has technical issues.
>
> IIRC the only issue is that if you sign such a randomly-named file,
> the signature isn't valid for the correctly-named file. Well, people
> whose signatures count can rename the tarball locally before signing
> it.
I think that would get us into a degree of complexity we don't want.
Simplicity is: you get handed an object, you test it, sign it, and
post your signature.
Complexity is: anything more than that :-).
Re Greg's comments: I'm not 100% happy either with a method that can
result in the first release in a series being something other than
".0". But I'm not 100% happy with the alternatives either, and at
least we can always put something in the release notes explaining what
happened, so those who bother to read the notes will not be confused.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
> On Tue, 2006-01-31 at 14:37 -0800, Garrett Rooney wrote:
>
>>>> No, thanks to the RCs that catch most of the problems. It would have
>>>> been 1.3.1, though, instead of 1.3.0 (if I recall the series of events
>>>> correctly).
>>>>
>>> FWIW, isn't that what httpd does?
>>>
>> I'm not positive about HTTPD, but APR does something like that. We've
>> burned through two version numbers for the current APR release due to
>> issues that were not caught until the tarballs were out there being
>> tested. Not that it's a big deal though, version numbers are cheap
>> ;-)
>>
>
> I think this is an error. Version numbers mean something to users, so
> they aren't *that* cheap. Having the first 1.3 release of Subversion be
> 1.3.1 would have been confusing to some people, and falsely reassuring
> to others (who avoid .0 releases out of conservatism).
>
> So, I'm not 100% happy with a process that causes us to burn version
> numbers when a tarball fails testing. In the past, I've advocated
> naming the tarball something random when we post it, but apparently that
> has technical issues.
>
IIRC the only issue is that if you sign such a randomly-named file, the
signature isn't valid for the correctly-named file. Well, people whose
signatures count can rename the tarball locally before signing it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2006-01-31 at 14:37 -0800, Garrett Rooney wrote:
> > > No, thanks to the RCs that catch most of the problems. It would have
> > > been 1.3.1, though, instead of 1.3.0 (if I recall the series of events
> > > correctly).
> >
> > FWIW, isn't that what httpd does?
>
> I'm not positive about HTTPD, but APR does something like that. We've
> burned through two version numbers for the current APR release due to
> issues that were not caught until the tarballs were out there being
> tested. Not that it's a big deal though, version numbers are cheap
> ;-)
I think this is an error. Version numbers mean something to users, so
they aren't *that* cheap. Having the first 1.3 release of Subversion be
1.3.1 would have been confusing to some people, and falsely reassuring
to others (who avoid .0 releases out of conservatism).
So, I'm not 100% happy with a process that causes us to burn version
numbers when a tarball fails testing. In the past, I've advocated
naming the tarball something random when we post it, but apparently that
has technical issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/31/06, Daniel Rall <dl...@collab.net> wrote:
> On Tue, 31 Jan 2006, Karl Fogel wrote:
>
> > Mark Phippard <ma...@softlanding.com> writes:
> > > Does this mean that the "GA" release of Subversion 1.3 might have been
> > > release 1.3.8?
> >
> > No, thanks to the RCs that catch most of the problems. It would have
> > been 1.3.1, though, instead of 1.3.0 (if I recall the series of events
> > correctly).
>
> FWIW, isn't that what httpd does?
I'm not positive about HTTPD, but APR does something like that. We've
burned through two version numbers for the current APR release due to
issues that were not caught until the tarballs were out there being
tested. Not that it's a big deal though, version numbers are cheap
;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 31 Jan 2006, Karl Fogel wrote:
> Mark Phippard <ma...@softlanding.com> writes:
> > Does this mean that the "GA" release of Subversion 1.3 might have been
> > release 1.3.8?
>
> No, thanks to the RCs that catch most of the problems. It would have
> been 1.3.1, though, instead of 1.3.0 (if I recall the series of events
> correctly).
FWIW, isn't that what httpd does?
--
Daniel Rall
Re: Release policy question
Posted by kf...@collab.net.
Mark Phippard <ma...@softlanding.com> writes:
> Does this mean that the "GA" release of Subversion 1.3 might have been
> release 1.3.8?
No, thanks to the RCs that catch most of the problems. It would have
been 1.3.1, though, instead of 1.3.0 (if I recall the series of events
correctly).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@collab.net> wrote on 01/31/2006 04:56:28 PM:
> On Tue, 31 Jan 2006, Karl Fogel wrote:
>
> > Daniel Rall <dl...@collab.net> writes:
> > > I too prefer Greg's suggested strategy. It's simpler, and results
in
> > > less possibility for errors when referring to a release, since it
> > > needn't be qualified with "rcX".
> >
> > Hmm. Somebody is misunderstanding something here, but I'm not sure if
> > it's you, me, or Greg, or some combination therewhom :-).
> >
> > IIUC, Greg wasn't proposing getting rid of the "-rcX" tarballs. He
> > was just saying let's never issue two tarballs with different content
> > but the same name (something we currently can do, and have done,
> > albeit in very limited circumstances).
>
> I'm saying it's simplest to call the new tarball x.y.(z + 1), if the
> previous tarball was named x.y.z. I'm advocating that approach even
> when nothing meaningful in the source code has changed between
> tarballs. I believe we've done this in the past when a tarball has
> been DOA.
Does this mean that the "GA" release of Subversion 1.3 might have been
release 1.3.8?
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 31 Jan 2006, Karl Fogel wrote:
> Daniel Rall <dl...@collab.net> writes:
> > I too prefer Greg's suggested strategy. It's simpler, and results in
> > less possibility for errors when referring to a release, since it
> > needn't be qualified with "rcX".
>
> Hmm. Somebody is misunderstanding something here, but I'm not sure if
> it's you, me, or Greg, or some combination therewhom :-).
>
> IIUC, Greg wasn't proposing getting rid of the "-rcX" tarballs. He
> was just saying let's never issue two tarballs with different content
> but the same name (something we currently can do, and have done,
> albeit in very limited circumstances).
I'm saying it's simplest to call the new tarball x.y.(z + 1), if the
previous tarball was named x.y.z. I'm advocating that approach even
when nothing meaningful in the source code has changed between
tarballs. I believe we've done this in the past when a tarball has
been DOA.
--
Daniel Rall
Re: Release policy question
Posted by kf...@collab.net.
Daniel Rall <dl...@collab.net> writes:
> I too prefer Greg's suggested strategy. It's simpler, and results in
> less possibility for errors when referring to a release, since it
> needn't be qualified with "rcX".
Hmm. Somebody is misunderstanding something here, but I'm not sure if
it's you, me, or Greg, or some combination therewhom :-).
IIUC, Greg wasn't proposing getting rid of the "-rcX" tarballs. He
was just saying let's never issue two tarballs with different content
but the same name (something we currently can do, and have done,
albeit in very limited circumstances).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Daniel Rall <dl...@collab.net>.
On Sun, 29 Jan 2006, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > I would still be concerned with changes in dist.sh. That has a very
> > real effect upon the tarball. What if the new tarball picked up a
> > different copy of Neon? Or maybe used a new SWIG to generate a
> > different set of bindings?
> >
> > Point is: any new tarball can be different. And when bugs start coming
> > in, how are you going to distinguish them? This was the basis of the
> > "burn a version number. they're cheap." rule.
> >
> > If the very first release was called 1.3.1, then it is easy to
> > explain. "We rolled 1.3.0 and found problems. Thus, we rolled a 1.3.1,
> > and it was qualified for release." It's a very simple FAQ to answer.
> >
> > Yes, -rc candidate are present to try and avoid that situation (as it
> > *is* a bit strange), but it really is fine to just start burning
> > release numbers. I would much rather see a FAQ entry than an ambiguous
> > "1.3.0" in problem reports.
>
> Well, +1 here. I favor the policy you describe above more than the
> policy I just committed :-). But as far as I can tell I was the only
> one in the discussion (at the time) who felt that way, and it wasn't
> important enough to me to argue strongly for it.
>
> If you want re-make the case for the "always use a new number" policy,
> count me as one 'aye' vote. It's not a big deal to me, though, since
> we're only talking about unblessed tarballs here (and thus a
> relatively small window of time in which confusion could happen).
I too prefer Greg's suggested strategy. It's simpler, and results in
less possibility for errors when referring to a release, since it
needn't be qualified with "rcX".
--
Daniel Rall
Re: Release policy question
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> I would still be concerned with changes in dist.sh. That has a very
> real effect upon the tarball. What if the new tarball picked up a
> different copy of Neon? Or maybe used a new SWIG to generate a
> different set of bindings?
>
> Point is: any new tarball can be different. And when bugs start coming
> in, how are you going to distinguish them? This was the basis of the
> "burn a version number. they're cheap." rule.
>
> If the very first release was called 1.3.1, then it is easy to
> explain. "We rolled 1.3.0 and found problems. Thus, we rolled a 1.3.1,
> and it was qualified for release." It's a very simple FAQ to answer.
>
> Yes, -rc candidate are present to try and avoid that situation (as it
> *is* a bit strange), but it really is fine to just start burning
> release numbers. I would much rather see a FAQ entry than an ambiguous
> "1.3.0" in problem reports.
Well, +1 here. I favor the policy you describe above more than the
policy I just committed :-). But as far as I can tell I was the only
one in the discussion (at the time) who felt that way, and it wasn't
important enough to me to argue strongly for it.
If you want re-make the case for the "always use a new number" policy,
count me as one 'aye' vote. It's not a big deal to me, though, since
we're only talking about unblessed tarballs here (and thus a
relatively small window of time in which confusion could happen).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jan 29, 2006 at 06:13:00PM -0600, kfogel@collab.net wrote:
> Erik Huelsmann <eh...@gmail.com> writes:
> > > I would say that if any code changes, it *must* get a new version number.
> > > If it's just a re-roll due to a dist.sh or packaging problem, then it can
> > > use the same version number. However, there is never a legitimate reason
> > > to re-use a version number if the code has actually changed. -- justin
> >
> > I agree with Justin that this is how I'd like to handle this in this
> > case: there's no difference in the code shipped, nor is there any
> > difference in any other significant part of the archive.
>
> Okay, clarified policy committed in r18287, comments welcome.
I would still be concerned with changes in dist.sh. That has a very
real effect upon the tarball. What if the new tarball picked up a
different copy of Neon? Or maybe used a new SWIG to generate a
different set of bindings?
Point is: any new tarball can be different. And when bugs start coming
in, how are you going to distinguish them? This was the basis of the
"burn a version number. they're cheap." rule.
If the very first release was called 1.3.1, then it is easy to
explain. "We rolled 1.3.0 and found problems. Thus, we rolled a 1.3.1,
and it was qualified for release." It's a very simple FAQ to answer.
Yes, -rc candidate are present to try and avoid that situation (as it
*is* a bit strange), but it really is fine to just start burning
release numbers. I would much rather see a FAQ entry than an ambiguous
"1.3.0" in problem reports.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question (was: Re: 1.3.0 tarballs up for testing/signing (again))
Posted by kf...@collab.net.
Erik Huelsmann <eh...@gmail.com> writes:
> > I would say that if any code changes, it *must* get a new version number.
> > If it's just a re-roll due to a dist.sh or packaging problem, then it can
> > use the same version number. However, there is never a legitimate reason
> > to re-use a version number if the code has actually changed. -- justin
>
> I agree with Justin that this is how I'd like to handle this in this
> case: there's no difference in the code shipped, nor is there any
> difference in any other significant part of the archive.
Okay, clarified policy committed in r18287, comments welcome.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release policy question (was: Re: 1.3.0 tarballs up for testing/signing (again))
Posted by Erik Huelsmann <eh...@gmail.com>.
On 1/2/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Fri, Dec 30, 2005 at 08:01:03PM -0600, kfogel@collab.net wrote:
> > In the past, we had a policy that once a tarball is mentioned in a
> > public forum, that name is used up, and any new tarball must have a
> > new name. But now, two different tarballs have been released into the
> > world under the name "1.3.0". Is this something we discussed and
> > decided we could live with?
>
> > (Yes, the old policy meant that if there was some problem with 1.3.0,
> > then the first "real" 1.3.x release would be 1.3.1. One purpose of
> > the "-rcX" releases preceding the first ".0" release in a series is to
> > minimize the chance of this happening... but if it did happen, it
> > wasn't supposed to be a disaster. In the old policy, maintaining
> > unambiguous uniqueness was considered most important.)
>
> Correct.
>
> > I don't see anything in www/hacking.html or notes/releases.txt to
> > resolve my question. I do recall some discussions in the semi-recent
> > past about this, so maybe we decided to loosen the policy (David's use
> > of "r17949" to disambiguate is an example of why this can work).
> >
> > If we are all agreed that the new policy is
> >
> > "We will try as hard as we can, through the use of RCs, to avoid
> > releasing different tarballs under the same name. But we may
> > still allow it to happen as long as the tarball of that name is
> > still in testing/signing and has not been officially 'blessed'."
> >
> > then I (or someone) can update hacking.html accordingly.
> >
> > Thoughts?
>
> I would say that if any code changes, it *must* get a new version number.
> If it's just a re-roll due to a dist.sh or packaging problem, then it can
> use the same version number. However, there is never a legitimate reason
> to re-use a version number if the code has actually changed. -- justin
I agree with Justin that this is how I'd like to handle this in this
case: there's no difference in the code shipped, nor is there any
difference in any other significant part of the archive.
bye,
Erik.
Re: Release policy question (was: Re: 1.3.0 tarballs up for testing/signing (again))
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Dec 30, 2005 at 08:01:03PM -0600, kfogel@collab.net wrote:
> In the past, we had a policy that once a tarball is mentioned in a
> public forum, that name is used up, and any new tarball must have a
> new name. But now, two different tarballs have been released into the
> world under the name "1.3.0". Is this something we discussed and
> decided we could live with?
> (Yes, the old policy meant that if there was some problem with 1.3.0,
> then the first "real" 1.3.x release would be 1.3.1. One purpose of
> the "-rcX" releases preceding the first ".0" release in a series is to
> minimize the chance of this happening... but if it did happen, it
> wasn't supposed to be a disaster. In the old policy, maintaining
> unambiguous uniqueness was considered most important.)
Correct.
> I don't see anything in www/hacking.html or notes/releases.txt to
> resolve my question. I do recall some discussions in the semi-recent
> past about this, so maybe we decided to loosen the policy (David's use
> of "r17949" to disambiguate is an example of why this can work).
>
> If we are all agreed that the new policy is
>
> "We will try as hard as we can, through the use of RCs, to avoid
> releasing different tarballs under the same name. But we may
> still allow it to happen as long as the tarball of that name is
> still in testing/signing and has not been officially 'blessed'."
>
> then I (or someone) can update hacking.html accordingly.
>
> Thoughts?
I would say that if any code changes, it *must* get a new version number.
If it's just a re-roll due to a dist.sh or packaging problem, then it can
use the same version number. However, there is never a legitimate reason
to re-use a version number if the code has actually changed. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org