[nycbug-talk] FreeBSD security and errata "P numbers"

[Brian Callahan]

This might not be the most glorified of solutions, but I've always
found the -p numbers as a convenience more than anything else. Though
I don't personally use freebsd-update, I always make sure to write
down by hand the dates and time of updates to my machines and machines
in my care.

Of course, depending on how many servers you need to check on, this
quickly becomes tedious to impossible, but I've always found having a
paper trail of what I did and when to be the best way to check whether
or not my machines are updated.

On another note, have you brought this up with Colin Percival? Maybe
he has a solution.

On 1/11/11, Mark Saad <mark.saad at ymail.com> wrote:
> Talk
>   I know there have been a few discussions about how the current
> FreeBSD security and errata   "P numbers" are implemented .
> For starters the "-p numbers " are currently only implemented via
> newvers.sh as BRANCH variables .
>
> Take this snippit from newvers.sh on FreeBSD 7.3-RELEASE
>
> REVISION="7.3"
> BRANCH="RELEASE-p3"
> if [ "X${BRANCH_OVERRIDE}" != "X" ]; then
>        BRANCH=${BRANCH_OVERRIDE}
> fi
> RELEASE="${REVISION}-${BRANCH}"
> VERSION="${TYPE} ${RELEASE}"
>
> That's it, when you rebuild your kernel using updated sources the
> kernel's RELEASE is set to $REVISON-$BRANCH
> in this case 7.3-RELEASE-p3 .
>
> Think about this point, say in BRANCH  p1, and p2 there are no kernel
> bugs, freebsd-update will never update the
> BRANCH variable in the kernel on your system as it has not downloaded
> a new kernel compiled with the new BRANCH variable.
>
> Freebsd-update uses its magic shell scripts to compare your running
> system with an update server's binaries and bspatch(s)
> by using this its able to tell you if you are running BRANCH -pN or -pN+1 .
>
> Well what do I do when I cant get to the update server and I never
> have the sources on my computer. I would not be able to verify
> what actual BRANCH I am running with out serious checking.
>
> More commonly I have a group of servers I want o verify what kernel
> they are running and what they have installed. I can manually create a
> list of hashes, md5, sha1 etc, for known kernels and check uname
> and the hashs for /boot/kernel/kernel . This is not quick to whip this
> up. It would be
> nice if there was a better way to check this.
>
> Well what do you do about this talk ?  I have seen a few solution,
> some of them are simple from creating a /etc/release file with some
> info in it, to building system packages for parts of the base system
> and kernel once a fiscal quarter like 8.0-RELEASE-2010Q4 .
>
> So I said it syspkg (system packages) , netbsd had a project a few
> years ago to build installable packages for base parts of the system .
> This thread sums up what happened with that
>
> http://mail-index.netbsd.org/netbsd-desktop/2009/02/19/msg000091.html
>
> the most memorable quote here is
>
> "anyone doing the work is likely to encounter a vocal minority of
> users who think packages are the work of satan, which would be
> discouraging."
>
> So like I said what do you do ?
>
>
> ---
>
> Mark Saad
> mark.saad at ymail.com
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
>