[EPEL-devel] Re: What to do about an incompatible update I approved
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 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@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 > > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: What to do about an incompatible update I approved
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. 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@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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: What to do about an incompatible update I approved
On Wed, Oct 19, 2022 at 5:42 PM Dave Dykstra via epel-devel < epel-devel@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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
