protocol flaw. [09:15]
Correctly handle failures from unsetenv resulting from a corrupt
environment in rtld-elf. [09:16]
Fix permissions in freebsd-update in order to prevent leakage of
sensitive files. [09:17]
Approved by: so (cperciva)
Security: FreeBSD-SA-09:15.ssl
Security: FreeBSD-SA-09:16.rtld
Security: FreeBSD-SA-09:17.freebsd-udpate
using freebsd-update. This applies to using freebsd-update in "upgrade
mode" and normal freebsd-update on a security branch.
The backup kernel will be written to /boot/kernel.old, if the directory
does not exist, or the directory was created by freebsd-update in a
previous backup. Otherwise freebsd-update will generate a new directory
name for use by the backup. By default symbol files are not backed up
to save diskspace and avoid filling up the root partition.
This feature is fully configurable in the freebsd-update config file,
but defaults to enabled.
MFC after: 1 week (stable/7)
Reviewed by: cperciva
Approved by: re (kib)
non-matching index lines. This fixes a bug where bogus warnings would
be printed file has the wrong file flags AND has been updated by
FreeBSD Update.
Reported by: Royce Williams
version of freebsd-update, but I took it out when I rewrote everything
and added FreeBSD Update to the base system because I didn't think it
was useful. It turns out that quite a few people liked it and wanted
it back.
Requested by: Royce Williams + others
MFC after: 2 weeks
shared libraries.
This fixes a problem which resulted in 6.x->7.x upgrades having the
/usr/lib/libpthread.so -> libthr.so symlink missing; what happened was
that the old libpthread.so symlink pointed to /lib/libpthread.so.2 --
which matched the "/lib/*\.so\.[0-9]+" regex -- but the new symlink
didn't, so FreeBSD Update got confused and deleted the symlink as part
of its "remove old shared libraries" step.
To recreate the symlink (which I understand is necessary for ports like
KDE to build) on a 7.x system which FreeBSD Update upgraded from 6.x:
# ln -s libthr.so /usr/lib/libpthread.so
Reported by: Dmitry RCL Rekman
Help diagnosing bug from: kris
MFC after: 7 days
shared object files which have the same name as currently-installed
shared object files should be reinstalled after binaries are rolled
back. The order for rolling back updates is therefore
1. Install any old shared object files which can be installed without
overwriting a new shared object file.
2. Rollback everything which isn't a shared object or kernel file.
3. Rollback any shared object files which we didn't deal with in (1).
4. Rollback to the old kernel.
Bug reported by: Jan Henrik Sylvester
MFC after: 3 days
upgrading to new releases. Important parts of this code include
* automatically determining which optional components (e.g., src,
info, proflibs) are installed.
* merging changes in files which are modified locally and have
changed between the currently running and new release.
* prompting the user to rebuild all 3rd party software before
deleting old shared libraries.
Yes, this is compatible with "freebsd-update rollback" -- you can
test a new -BETA and roll back to the old release if you don't
like it.
Subject to re@ approval, this will be MFCed before 7.0-BETA3 and
6.3-RC1.
MFC after: 2 days
* When installing updates, make sure that securelevel <= 0. Otherwise
we can't remove the schg flag from files.
* When preparing to download updates, check to see if we already have
them sitting in the /files/ directory. This saves bandwidth if users
run "freebsd-update fetch" more than once without installing updates
in between.
While I'm here, bump the copyright date.
MFC after: 3 days
from EoL minus 6 months to EoL minus 3 months, in order to increase the odds
of there actually being a more recent release to which users can upgrade.
(In particular, for releases which are only supported for 12 months, it's
quite likely that the next release will occur between 6 and 9 months later.)
Discussed with: kensmith
Approved by: re (bmah)
MFC after: 3 days
patching and for rolling back updates, don't copy a file if it has already
been stored. This provides a significant speedup to the "Preparing to
download files" stage of "freebsd-update fetch" if many updates have already
been applied or if a file being updated is linked many times (such as
/rescue/*).
Reported by: Paul Dekkers
MFC after: 1 week
Approved by: re (bmah)
operating with the "-b basedir" option would not correctly update files
which had flags set or were hardlinked.
Submitted by: Karsten Schmidt
Pointy hat to: cperciva
MFC after: 1 week
1. When downloading metadata files, make sure we only download each
file once; without this fix, "freebsd-update fetch" will fail the first
time it is run if there have been no updates yet for the installed
release.
2. If the FOO kernel is installed in /boot/kernel instead of /boot/FOO
and the /boot/FOO directory does not exist, don't try to update
/boot/FOO. This is an issue only where an update involves adding a new
kernel module.
3. When removing files and directories, operate in reverse
lexographical order, in order to ensure that files are removed before
the directory which contains them.
MFC after: 3 days
