On Wed, Oct 19, 2022 at 5:42 PM Dave Dykstra via epel-devel <epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hello all,
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:
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
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/). On
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?
Better late than never. Please send an email to epel-announce saying what changed and why.
I'm not seeing any installation problems because of it, so I don't think you have to worry about other packages.
Having an email explaining what was updated and why allows us to point people to the explanation when they have questions.
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?
If this is a recurring thing, then I believe the answer is "sortof".
You don't have to come to the council meeting each time, but you should send out an email to epel-announce saying that it is happening and why.
I'm not seeing any epel7 golang dependency problems.
I would check to see if it really is an incompatible upgrade. Usually RHEL tries to keep things compatible, so if you are following their lead, often things are good.
Troy
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
