[EPEL-devel] Re: KDE broken on CentOS Stream 9

[Troy Dawson]

I have a new update set.  This is just the packages failing to install with
the updated qt5.  The qt5 packages are updated to match the versions that
are now in RHEL.  All other packages are still the same versions and
patches as before, just with their release bumped and then rebuilt.
These are now working on all of my tests.  And willit is showing that
everything is installing correctly.  So I think this time I got it right.

To test:
  dnf --enablerepo=epel-next-testing clean all
  dnf --enablerepo=epel-next-testing update

To give karma:
  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2023-22498da84c


On Wed, May 17, 2023 at 8:58 AM Troy Dawson  wrote:

> KDE is still not able to be upgraded in CentOS Stream 9.
> This is my fault.
> I tried to combine the rebuilds needed for the new qt5, with updating the
> rest of the KDE Plasma Desktop.  This didn't go well.
> I will be removing the updates from epel-next-testing and starting again
> with just the packages that need a rebuild due to the qt5 update.
>
> I'm sorry for the inconvenience, and appreciate the patience you have
> shown.
>
> Troy
>
> On Fri, May 5, 2023 at 7:11 AM Troy Dawson  wrote:
>
>> There is a new qt5 update in CentOS Stream 9.  This update will be going
>> out when RHEL 9.3 is released six months from now.  Again, that is RHEL
>> 9.3, NOT 9.2.
>>
>> I am currently rebuilding KDE for CentOS Stream 9.  This will take some
>> time to rebuild and make it through testing.  I am suspecting it will not
>> be in stable until May 18.
>>
>> It is a known issue that is being resolved.  No need for further bugs.
>> If you have already created a bug, please cc me (tdaw...@redhat.com) on
>> it, because most of the bugs do not get assigned to me.
>>
>> Thank You
>> 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: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

Carl,

You don't seem to have looked at this closely enough to understand.
This is not an ordinary security problem that can be worked around in a
compatible way.  The security vulnerability is the feature itself.
There's nothing that can be done about it short of disabling the feature.

Of course if there was a compatible way to deal with this security
vulnerability, we would have done it.

Dave

On Thu, May 11, 2023 at 10:34:40PM -0500, Carl George wrote:
> Tens of thousands of upstream projects are packaged into Fedora and
> EPEL.  If they can find ways to deliver security fixes while following
> Fedora and EPEL update policies, then apptainer can too.  Asking you
> to follow these policies is not a punishment.  If you're unwilling to
> follow these policies, then I agree with Troy that copr will be a
> better fit for apptainer.
> 
> On Thu, May 11, 2023 at 11:51 AM Dave Dykstra via epel-devel
>  wrote:
> >
> > To Troy and the reset of the EPEL Steering Committee:
> >
> > Thank you very much for granting the request.
> >
> > The apptainer maintainers promise to do our best to avoid incompatible
> > updates in the future.  However if we discover another high severity
> > vulnerability in the setuid-root portion that cannot be worked around in
> > a compatible way, you will have put us into a very difficult position of
> > deciding between protecting the security of our users and making this
> > popular software more difficult for them to install.  It doesn't make
> > sense to me that packages should be punished for doing what they are
> > forced to do for good security.
> >
> > Dave
> >
> > On Wed, May 10, 2023 at 02:20:52PM -0700, Troy Dawson wrote:
> > > We discussed this in the weekly EPEL Steering Committee meeting. We broke
> > > this into two separate votes.
> > >
> > > *Allow the epel 7 update : Passed*
> > > Votes: All who voted, voted in favor of this.
> > > Notes: No notes.
> > >
> > > *Allow the epel 8 and 9 update - with a stern warning : Passed*
> > > Votes: 4 for, 2 against, 1 abstaining -
> > > Notes: Although your argument was that these needed the same breaking
> > > configurations to prevent future security issues, that wasn't what swayed
> > > the votes. The first reason was that having older versions in epel 8 and 9
> > > causes more problems. The second reason was that we felt we didn't give 
> > > you
> > > a stern enough warning last time.
> > >
> > > *WARNING / ADVISEMENT / ATTENTION*
> > > This is the second time that apptainer has had breaking updates. The EPEL
> > > Steering Committee feels that if this happens again, then apptainer isn't 
> > > a
> > > good fit for EPEL. We will pull apptainer from EPEL and recommend that you
> > > release it in COPR  instead of EPEL.
> > > Please inform the upstream maintainers of this.
> > >
> > >
> > > Troy
> > >
> > > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  wrote:
> > >
> > > > Hi Troy,
> > > >
> > > > If required, the epel8 & epel9 builds could have a patch added that
> > > > changes the default of the new "allow setuid-mount extfs" to be "yes"
> > > > instead of "no". That's all that would be required to disable the
> > > > incompatible change.
> > > >
> > > > But as I said, I think it's a bad idea to make this behavior different
> > > > on different OS versions.  Epel8 & 9 are still vulnerable to the same
> > > > general issue; even though they're likely to get patches for future low
> > > > or moderate level severity vulnerabilities, they don't get patches
> > > > quickly and so admins will have to turn this off for the period of time
> > > > between announcement and patch upstream.  Also the incompatibility is
> > > > going to only affect a small percentage of epel8 & 9 users, and they
> > > > should be able to quickly workaround it by adding the --userns option.
> > > >
> > > > The --userns option is already available everywhere.  Are you
> > > > suggesting that it default to --userns option behavior on epel8 & 9, at
> > > > least for ext3, when "allow setuid-mount extfs = no"?  I have thought
> > > > of that but I believe that we cannot mix the setuid mode and the
> > > > fuse2fs mount, at least not without a lot of major rework and careful
> > > > investigation of the security implications.  I don't think it would be
> > > > good to automatically switch fully to the --userns mode with a setuid
> > > > installation and "allow setuid-mount extfs = no", because then users
> > > > will get subtle differences with other behavior depending on whether or
> > > > not they are requesting something that is using an ext3 filesystem.
> > > >
> > > > Dave
> > > >
> > > > On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote:
> > > > > That makes it more clear for epel7.
> > > > > But it will be strange for epel7 to have a higher version than epel8 
> > > > > and
> > > > 9.
> > > > > Would the apptainer maintainers be willing to create an update that 
> > > > > has
> > > > the
> > > > > --userns o