Date: Sat, 15 Jul 2000 11:54:04 +0200 From: Stijn Hoop <stijn@win.tue.nl> To: "Bruce A. Mah" <bmah@cisco.com> Cc: Warner Losh <imp@village.org>, ports@freebsd.org Subject: Re: Version question/request Message-ID: <20000715115404.D92785@pcwin002.win.tue.nl> In-Reply-To: <200007150550.e6F5o0P02257@bmah-freebsd-0.cisco.com>; from bmah@cisco.com on Fri, Jul 14, 2000 at 10:50:00PM -0700 References: <200007150511.XAA01511@billy-club.village.org> <200007150550.e6F5o0P02257@bmah-freebsd-0.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 14, 2000 at 10:50:00PM -0700, Bruce A. Mah wrote: > If memory serves me right, Warner Losh wrote: > > I'd like to create a script that runs in /etc/security that will > > produce output like the following: > > > > YOUR SYSTEM HAS THE FOLLOWING PORTS THAT HAVE KNOWN SECURITY ISSUES IN > > THE VERSION YOU ARE RUNNING: > > woofootd (have 2.1 need 2.2) > > qpooper (have 2.98 need 3.11) > > etc Cool idea! > Nice. One thing I'd suggest is that the script gets updated as a part > of the Ports Collection, rather than as one of the source collections. > I'm presuming that many users will cvsup their Ports Collection tree > far more frequently than they'd do a make world. I second this. > > This works great most of the time, however there are times that it > > doesn't work. Those times are where we've either F'ed up a patch so > > there's a security hole or we patch it with a patch-xx file before the > > author can issue a new release. In these cases when the problem is > > fixed, I'd love the version number to change with (or soon after) the > > security patch goes into the tree. > > Well, I think it's not a bad idea for updating ports in general (in > other words, we add a patchfile to fix a bug, so the user should > reinstall, even though the version number of the underlying software > didn't change. So I can see some more general utility beyond dealing > just with security issues (though these are probably the most important > examples). That's what bugged me for a time too - as a user you have to follow the commit messages to see whether a bug is fixes (like recently with gdk-pixbuf), and consequently when to reinstall the same version of a package (although freshports.org fixes that somewhat ;) But a general 'FreeBSD version' would be very nice. Note that most Linux'en do this already by adding a simple number after the version number of the package. Not a 'me too', but rather an 'it's proven technology'. > > Does anybody have any good ideas on how to do the version number part > > of this? I was thinking of adding a known suffix like "-S1" for the > > first security fix "-S2" for the second, etc. Then when the author > > fixes it and generates his own version, the suffix goes away. This > > would give us wu-ftpd-2.6.1-S2 which will sort after 2.6.1 but before > > 2.6.2. Hmmm, that does assume that the author fixes it in his/her/its > > next release, so maybe some other tag is needed. > > When I was working on pkg_version, I thought of having something that > tracks the last time any of a Port's files get modified. It'd have to > be automatic, because otherwise, updating a port would be too painful. > We can't depend on the modification dates of (e.g.) the Makefile or the > patchfiles. I'm wildly guessing here, but is it perhaps possible to write some scripts that are run at 'cvs ci' time that increment a number in the Makefile, or something? > Here's a wild thought. You proposed having the version number > supercede a "security fix" number. What about having the "security > fix" number supercede the version number? You start off having a > security fix number of zero. The first time you issue an advisory (and > commit a fix to the Ports Collection tree), you increment the security > fix number. If the author fixes it (and bumps the version number) > that's fine. In other words: > > Fix Version > 0 1.0 # first release > 0 1.1 # normal version update > 1 1.1 # security fix issued against 1.1 > # make sure users have at least fix=1, > # version 1.1 > 1 1.2 # author fixed it, but we keep fix=1, > # users are still OK with fix=1, version 1.1 > > 2 1.2 # another security hole, advisory fixed > 3 1.2 # yet another hole, author still hasn't > # done anything but as long as users > # have at least fix=3, version=1.2, > # they're "safe" > 3 1.3 # author finally fixed it > > I have to think about implications for pkg_version now, if any. I don't > think the security fix number belongs as a part of the version number > (e.g. xmmix-1.2), but I can't think of a clean way to do this otherwise. Well I'd follow the standard naming conventions e.g. package foo, version 1.2, FreeBSD version 2 becomes foo-1.2-2. pkg_version can be modified to check for the FreeBSD version bump first. > I wonder if this is going to make any sense after I wake up in the > morning... :-p It did to me at least ;) --Stijn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000715115404.D92785>