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 [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
