Date: Fri, 14 Jul 2000 22:50:00 -0700 From: bmah@cisco.com (Bruce A. Mah) To: Warner Losh <imp@village.org> Cc: ports@FreeBSD.ORG Subject: Re: Version question/request Message-ID: <200007150550.e6F5o0P02257@bmah-freebsd-0.cisco.com> In-Reply-To: <200007150511.XAA01511@billy-club.village.org> References: <200007150511.XAA01511@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1071788520P Content-Type: text/plain; charset=us-ascii 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 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. > 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). > 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. 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. I wonder if this is going to make any sense after I wake up in the morning... :-p Bruce. --==_Exmh_1071788520P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: GwDEiOro1E6T2JUPZPDBTAnT/0BECZco iQA/AwUBOW/7iNjKMXFboFLDEQJrNwCg6pUwoqa6Nkx5GdSuZSCNpQgRMPQAoIRA ua27p27HF0SJPapkYZgHAtln =s3lO -----END PGP SIGNATURE----- --==_Exmh_1071788520P-- 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?200007150550.e6F5o0P02257>