No updates needed to update system to 8.2-RELEASE-p6 but still
on 8.2-RELEASE-p3
Antonio Olivares
olivares14031 at gmail.com
Sun Feb 19 11:18:02 UTC 2012
On Sun, Feb 19, 2012 at 4:22 AM, Matthew Seaman
<m.seaman at infracaninophile.co.uk> wrote:
> On 19/02/2012 02:06, Antonio Olivares wrote:
>> On Sat, Feb 18, 2012 at 8:04 PM, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>>>
>>> Antonio,
>>> The 'upgrade' from _P5_ to P6 did not touch the kernel, hence the kernel ID
>>> did not change.
>>>
>>> Going from P3 you should have seen a kernel update.
>>>
>>> what do you see if you do "strings /boot/kernel/kernel |grep 8"
>>
>> It is a big file so I'll paste it to pastebin temporarily:
>>
>> http://pastebin.com/K1PsTa0P
>
> Heh. The interesting bit is on line 4301 -- the last line of that
> output. A slightly more selective grep term would have been a good idea.
>
> Anyhow, that shows the kernel on your system is 8.2-RELEASE-p3. Which
> implies that something ain't right somewhere.
>
> Four possibilities, roughly in order of severity:
>
> 1) None of the security patches between p3 and p6 did actually
> touch the kernel. You can tell if this was the case by looking
> at the list of modified files in the security advisory. The
> kernel is affected if any files under sys have been
> modified other than src/sys/conf/newvers.sh
>
> The last advisory that did touch the kernel was
> http://security.freebsd.org/advisories/FreeBSD-SA-11:05.unix.asc
>
> which should have given you 8.2-RELEASE-p4. However -- see
> below.
>
> 2) An oversight in the freebsd-update process upstream meaning that
> the operational patches were applied, but not the changes to the
> kernel version number when the replacement kernel was compiled.
> Unlikely, as newvers.sh is always updated on each of the security
> branches even if the update doesn't touch the kernel.
>
> 3) You've told freebsd-update not to touch your kernel. Unlikely,
> and not in the default config, but useful where people need to
> use a custom kernel and maintain the rest of the system with
> freebsd-update.
>
> In this case, you'ld have modified /etc/freebsd-update.conf to
> change:
>
> Components src world kernel
>
> to read:
>
> Components src world
>
> Also you should be expecting to have to rebuild your kernel from
> sources, so I doubt this is the case.
/etc/freebsd-update.conf has:
=====line 1 col 0 lines from top 1 ============================================
# $FreeBSD: src/etc/freebsd-update.conf,v 1.6.2.2.6.1 2010/12/21 17:09:25 kensmi
# Trusted keyprint. Changing this is a Bad Idea unless you've received
# a PGP-signed email from <security-officer at FreeBSD.org> telling you to
# change it and explaining why.
KeyPrint 800651ef4b4c71c27e60786d7b487188970f4b4169cc055784e21eb71d410cc5
# Server or server pool from which to fetch updates. You can change
# this to point at a specific server if you want, but in most cases
# using a "nearby" server won't provide a measurable improvement in
# performance.
ServerName update.FreeBSD.org
# Components of the base system which should be kept updated.
Components src world kernel
..... removed to save space ....
>
> 4) The kernel wasn't patched properly and hasn't been updated and
> you're still vulnerable.
>
> Now, I believe that in fact the situation is in fact as described in
> option (1) -- none of the patches since p3 have touched the kernel
> distributed through freebsd-update. (2) and (4) can be discounted -- if
> such egregious mistakes had been made, they would long ago have been
> noticed and corrected.
>
> Here is the thing I alluded to under option (1). The security patch for
> the unix domain socket problem came out in two chunks. There was an
> original patch to fix the actual security problem, then a later followup
> patch to fix a bug that exposed in the linux emulation layer. It is
> possible to tell this from the text of the advisory as it exists at the
> moment, but you might not see it unless you are looking for it. The
> important bit of text is this:
>
> NOTE: The patch distributed at the time of the original advisory fixed
> the security vulnerability but exposed the pre-existing bug in the
> linux emulation subsystem. Systems to which the original patch was
> applied should be patched with the following corrective patch, which
> contains only the additional changes required to fix the newly-
> exposed linux emulation bug:
>
> Given that the second part of the patch was actually not a security fix,
> there would not have been a modified kernel distributed. So you got a
> bundle of three advisories issued together on 2011-09-28 resulting in
> FreeBSD 8.2-RELEASE-p3. Then later on, at 2011-10-04 a further update
> was issued modifying FreeBSD-SA-11:05-unix and technically taking the
> system to FreeBSD 8.2-RELEASE-p4. However, as this was not a security
> fix, it was not applied to the freebsd-update distribution channel. As
> none of the updates since then have touched the kernel, it will still
> show -p3 even though you are in fact fully patched against all known
> security problems.
I hope this is the case, but that -p3 makes me think? I am hesistant
to move to 9.0-RELEASE as of yet. There will apparently be an
8.3-RELEASE and I am not sure whether I have to rebuild all ports if I
update to newer release. I have read some places that one does not
have to rebuild all ports, and just install compat8.x/ special port.
In FreeBSD Handbook, it still recommends to rebuild all ports. It
took me a while to get going last time I moved from 8.1-RELEASE to
8.2-RELEASE, so I am hesistant to do it :( And not being sure about
this, I am in the thinking process of what should I do.
>
> Cheers,
>
> Matthew
>
> --
> Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
> Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
> JID: matthew at infracaninophile.co.uk Kent, CT11 9PW
>
Thank you very much for your kind explanation and hopefully I am in
the (4) category. How does one know when a new 8.2-RELEASE-pX, has
been released? where X is a number >= 6?
Regards,
Antonio
More information about the freebsd-questions
mailing list