5:14 p.m.
Hi Dave,
I know I've seen emails about upgrades, so I guess people are sending it to
epel-devel instead of epel-announce. We'll have to make that more
prominent in the documentation or something.
On Thu, Oct 20, 2022 at 1:44 PM Dave Dykstra <dwd(a)fnal.gov> wrote:
Thanks, Troy. I will send a message to epel-announce.
I looked through the last couple of years of epel-announce archives and
don't see similar messages. I have a hard time imagining that somewhat
incompatible changes aren't happening to other packages too, so it seems
that such announcements aren't usually sent.
With regard to golang, they usually have some small incompatibilities
every minor upgrade. They do a new minor upgrade every 6 months, they
only support security updates for 2 minor release lines at a time, and
they have frequent CVEs, so the only viable option is to keep upgrading
the minor version number once or twice a year. There is a golang
fedoraproject.org mailing list. Maybe it's enough to announce minor
release upgrades there instead of epel-announce.
I don't think very many epel users are going to see the fedora golang
mailing list.
It would be best if it was one of the epel ones, or even both.
Troy
Dave
On Thu, Oct 20, 2022 at 01:18:30PM -0700, Troy Dawson wrote:
> On Wed, Oct 19, 2022 at 5:42 PM Dave Dykstra via epel-devel <
> epel-devel(a)lists.fedoraproject.org> 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