Date: Sat, 4 Aug 2001 09:47:32 -0400 From: Jonathan Chen <jon@FreeBSD.ORG> To: stable@FreeBSD.ORG Subject: Re: RELENG_4_3 calls itself -RELEASE? Message-ID: <20010804094732.A47919@enterprise.spock.org> In-Reply-To: <01080300314100.00395@spatula.home>; from andrew@cream.org on
next in thread | previous in thread | raw e-mail | index | archive | help
Fri$ Not to beat a -deadhorse, but here are my $.02 The only sensible suggestion I've seen so far is 4_3_x_RELEASE. The reason is that all the proposals I've seen (with the exception of the above and 4_3_RELEASEplX, which is not lexically bigger than 4_3_RELEASE) is merely a cosmetic change with no effect beyond the first security fix. Anyone who wants to find out whether their system has been patched will still have to resort to the old method. But there are still problems with checking the build date. Consider the following example: Admin X receives a security notification, and immediately goes to update his FreeBSD machines. Here, several scenarios can happen: 1) The cvsup server used does updates every 6 hours and/or missed the last update. Admin believes he has updated version. Admin's copy of SirCam is read by noisy hacker. 2) Two advisories are released in close proximity. Admin believes he has second fix when he in fact only has the first. Admin's site becomes the newest warez distribution point. 3) Another admin recompiles kernel for new driver. Admin X later receives advisory, and seeing that the machine is compiled post correction date, he believes that another admin fixed the problem. Site is compromised, and admin loses job/house/car/wife/kids. Here, I can offer several suggestions: 1) Have the cvs scripts add the latest commit date/time to a version.h everytime a commit occurs in a branch. Display/use it accordingly. 2) Embed the cvs $id/$FreeBSD strings in every binary. A security update tool can then be used to automagically determine whether a system has pending security issues. [I have no problems writing the aforementioned tool if we do decide to go this route] 3) Do nothing, and perhaps give more instructions in security advisories. -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010804094732.A47919>