Re: CVS commit: src/distrib/sets

[Jim Wise <jwise%draga.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 14 Jun 2003, Alistair Crooks wrote:

>So there are a number of things to take into consideration.
>
>Jim's naming scheme, in conjunction with the way that pkg_info(1) does
>its version numbering, mean that 1.6A is the same as 1.6.1.  This is
>not a good thing.

Which is well and good, except that neither of these are syspkg versions
which occur.  The corresponding syspkg versions are 1.6A.0 and 1.6.1.0,
which _are_ distinct.  Here and a couple places in your email, you refer
to packages having versions like `1.6T', which suggests you didn't read
the committed code, or my message.  To repeat:

A syspkgs version is the concatenation of the output of osrelease.sh
with a package-specific version, from src/distrib/sets/versions
(formerly from the package Makefile).  This means that when a relevant
change to the source of a package is made, it can be bumped from 1.6.0.0
to 1.6.0.1 (for example).


>Whatever does the kernel version have to do with a given userland
>package?

On the release branch, the `kernel version' is, in fact the most recent
number.  This maintains an easy and obvious ordering of syspkgs -- and
releases.


>The fact that people have to add the nb version number to another
>file doesn't fill me with awe and wonder. Developers are human, except
>for a few corner cases, and forget to update this file.

Sure -- but while it may run the risk of thinking you _haven't_
advanced, when in fact you have, you don't run the risk of thinking you
_have_ advanced, when in fact you haven't, something much more grave.

With the code you committed, if I read an SA and then recompile the same
code without updating it, I'm likely to get a new version of the package
- -- one dated _after_ the SA's `fixed' date, even though it still
contains the described vulnerability.


>Date-based comparison has been used in pkgsrc for the dependency
>checking for around 4 years, and works very well.

I can't think of a single place in pkgsrc where we use the dates _of
compiled binaries_ to version a package.  Can you?


>Now let's move onto the assertion:
>
>"documented, implemented, and committed previously, provides a constant
>version number for constant code, provides correct ordering for newer
>and older code, and gives us control over the granularity we want for
>syspkg version numbers."
>
>"provides correct ordering"? No, it doesn't.

How do you figure?  1.6.1.1 > 1.6.0.1 > 1.6.0.0.

In contrast, 20030801 may, in fact be _newer_ than 20030802, if the code
was cvs updated later, but compiled sooner.  Does that seem like a good
idea to anyone here?

>"control over the granularity"?  So 1.6T is good enough for everyone
>running -current?  When 1.6T has been the kernel version for 2 months?

Um, huh?  Again, you seem to have missed that a package has a last-dot
version number which is unique to that package.  So in the time that the
output of osrelease.sh is `1.6.0', a given package could progress
through

        1.6.0.1 -> 1.6.0.2 -> 1.6.0.3

Even better, each update of this number represents a relevant change,
such as an SA or added functionality -- not a mere recompile with or
without changed code.


>Jim hasn't explained why he doesn't like the date number, which is
>logical, simple, and requires no manual futzing.

Because you can look at the number and determine whether a change, such
as the fix for an SA, is there.  With the code before the change I
committed, recompiling would bump the version number with or without
changes.


>> I think there's probably good reason for the version numbers to
>> bump "automatically" too, such as when dependencies bump, and other
>> events.  We don't want to force all version bumps to require manual
>> developer effort - or some will be missed.
>>
>> In other words, for the SA case, I don't care how many other version
>> bumps happen between one SA for the ssh package and the next.  I
>> just need to be able to say in an SA: "if you have a version <X,
>> you are vulnerable to this issue, please upgrade to at least version
>> X".
>>
>> The simpler it is for users to determine this, the better.
>
>I completely agree.  "If you're running a package from before
>20030606, you're vulnerable" seems quite logical and simple to me.
>OTOH, "if you're running a package from 1.6Tnb2 on the -current
>branch, or 1.6.1nb5 on the -release branch" is a bit tenuous to me.

Except that the first of those statements is completely meaningless,
since recompiling a package on a later date without cvs updating will
(completely falsely) report that you have a fixed package -- and
presumes that all security fixes will hit the trunk and every branch on
the same date, while the latter statement matches _directly_ text you
will find in every SA the project has ever issued.

- -- 
                                Jim Wise
                                jwise%draga.com@localhost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)

iD8DBQE+6lwPlGcH240chEIRApsSAJkBlYvGMPfMtJfK5K05lYoQtVHU4ACg6Pst
TCdyAHe8tUuHdJQx+Kqs5IM=
=QNCI
-----END PGP SIGNATURE-----