getting the running patch level

[Roger Marquis]

Jilles Tjoelker wrote:
> I think the idea of having 'make installworld' create something is good,
> but we should not hard-code policy by writing the information into a
> file that may be shown to unauthenticated users (such as by getty).
> 
> A new file with a name=value format somewhat like /etc/lsb-release on
> Linux seems more appropriate. If the admin wants /etc/issue,
> /etc/rc.d/motd can create it.

Automatically updating /etc/issue (or /etc/issue.net, but not issue.*
should that be adopted from other OS) has security implications due to
potentially unintended information disclosure.

WRT writing a new file, something like /etc/bsd-release would be a good
choice following the principle of least surprise.  Mergemaster can and
should ignore it (and motd, issue, ...).

Strict adherence to the KIS principle, however, would only write this
information to the first line of the motd, after the kernel info.

Simon Nielsen wrote:
> A simple approach would be to just append -uX to the uname string, but I'm
> not really sure if I like that... To ilustrate, if for a 9.0 system, where
> kernel is patch 3 userland is patch 5, we would show FreeBSD
> 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and
> therefor are less likely to get it wrong.

There's not a good way to report on every userland (lib/binary) file but
a simple find and/or checksum (a la integrit) could indicate whether
anything had been updated since the last installworld.  That could be
noted by appending a simple "-modified" to whatever uname prints for the
userland version.  Attempting to do more than that, IMO, would have a
negative ROI.

IMO,
Roger Marquis