freebsd-update: improve pkgbase test

[emaste]

Summary

Packages such as freebsd-git-devtools and freebsd-ftpd are not indicative of packaged base, but match a default case-insensitive search.

Reported by: Mark Millard
Fixes: cf1aba2857c1 ("freebsd-update: refuse to operate on a pkgbase system")

[emaste]

usr.sbin/freebsd-update/freebsd-update.sh

1114

I also added the - in the expression since pkg base packages are of the form FreeBSD-... I don't think it's necessary but is more clear/precise.

[markmi_dsl-only.net]

Wondering somewhat beyond the specific changes here to the original commit . . . (I noticed by considering how I'd test the updated script.)

Should any freebsd-update commands be allowed for a PkgBase context?

Commands:
  fetch        -- Fetch updates from server
  cron         -- Sleep rand(3600) seconds, fetch updates, and send an
                  email if updates were found
  upgrade      -- Fetch upgrades to FreeBSD version specified via -r option
  updatesready -- Check if there are fetched updates ready to install
  install      -- Install downloaded updates or upgrades
  rollback     -- Uninstall most recently installed updates
  IDS          -- Compare the system against an index of "known good" files
  showconfig   -- Show configuration

fetch without allowing updates seems odd. (I'd have to undo the fetch somehow after testing.)
cron involves fetch.
upgrade involves fetch.
updatesready checks on the status of prior fetches.

That leaves IDS and showconfig .

Does IDS fit as a standalone check of "known good" files? (I doubt it for what PkgBase latest does, for example. But I have not checked the details.)

showconfig on its own does not seem to be worth avoiding the check for.

My guess is that all the commands should get the check. (Or the check should be factored out to always be done.)

usr.sbin/freebsd-update/freebsd-update.sh

1118

FreeBSD-update vs. freebsd-update :

# which FreeBSD-update
# which freebsd-update
/usr/sbin/freebsd-update

[emaste]

Should any freebsd-update commands be allowed for a PkgBase context?

I considered disallowing all commands, but originally settled on just those that would modify the installed base system and specifically conflict. But sure, it is easier to just disallow all use and easier to test. Will update.

[emaste]

Use pkg which /usr/bin/uname instead, to check for packaged base. pkg uses uname to determine ABI so it should exist.

This check should also work on CheriBSD or other downstreams.

[markmi_dsl-only.net]

Is pkg-static use appropriate because of things like when llibmd.so.6 -> libmd.so.7 happened? Both dependencies ended up involved, one indirectly via /usr/lib/liblzma.so.5 , stopping pkg from being able to run.

BACKUP_LIBRARIES=true in pkg.conf was not sufficient to avoid the problem.

libcrypto.so.* and libssl.so.* appear as other possible future examples of such as issue:

# ldd -a /usr/sbin/pkg | sort | uniq -c | sort -rn
  15 	libc.so.7 => /lib/libc.so.7 (0x2a7616b11000)
   4 	libcrypto.so.30 => /lib/libcrypto.so.30 (0x2a7614c0f000)
   3 	libthr.so.3 => /lib/libthr.so.3 (0x2a7619544000)
   2 	libsys.so.7 => /lib/libsys.so.7 (0x2a761a397000)
   2 	libssl.so.30 => /usr/lib/libssl.so.30 (0x2a76150b0000)
   2 	libmd.so.7 => /lib/libmd.so.7 (0x2a7616078000)
   1 [preloaded]
. . .
# ldd -a /usr/sbin/pkg
/usr/sbin/pkg:
        libarchive.so.7 => /usr/lib/libarchive.so.7 (0x2fc4b871e000)
        libfetch.so.6 => /usr/lib/libfetch.so.6 (0x2fc4b899b000)
        libprivateucl.so.1 => /usr/lib/libprivateucl.so.1 (0x2fc4b8a7e000)
        libcrypto.so.30 => /lib/libcrypto.so.30 (0x2fc4b8d68000)
        libssl.so.30 => /usr/lib/libssl.so.30 (0x2fc4b9f8c000)
        libutil.so.9 => /lib/libutil.so.9 (0x2fc4ba27b000)
        libmd.so.7 => /lib/libmd.so.7 (0x2fc4ba455000)
        libc.so.7 => /lib/libc.so.7 (0x2fc4bad34000)
. . .