It is been pointed out to me that I pushed out an update of a package to
EPEL that did not follow the incompatible upgrades policy:
That's because I wasn't aware of the policy until it was pointed out to
me (or possibly I had seen it once and had forgotten).
The incompatible change to the "apptainer" package that was pushed to
stable 3 weeks ago moved the setuid-root portion to another package
called "apptainer-suid", which does not get installed by default. The
remaining package can run non-setuid for most important operations, but
only if unprivileged user namespaces are enabled. This most effects
EPEL7 because unprivileged user namespaces are not enabled by default.
So the upgrade forces admins who haven't enabled them to either enable
them or install the extra package. This was done intentionally because
of the inherent risks associated with setuid programs, especially the
fact that the things that this program does with setuid (mounting
filesystems implemented in the kernel although the raw files are
writable by users) is something that kernel developers say should never
be allowed for unprivileged users (https://lwn.net/Articles/652468/
the other hand there aren't any known published exploits (anybody know a
good squashfs or ext3/4 filesystem developer who could find one?).
So the question is, what should be done about it since I didn't follow
the procedure before the release 3 weeks ago?
On a related note, I maintain golang in EPEL7 too, and every time that
RHEL8 upgrades to a new minor golang version number 1.X I do the same
for EPEL7. I expect that could be considered an incompatible update
too, although every time that's done there's a ton of CVEs that go along
with them so it's much easier to argue that the exceptions in the
incompatible upgrade policy apply. The question is, am I supposed to go
through the whole process every time?