I would be concerned if they're doing this in EPEL that they're doing it in Fedora too, and potentially would want to refer this to FESCo if we suspect it's not isolated to just EPEL.

It sounds like he mis-understood what you are asking, and to be honest, I would have also with your initial comment. It sounded like you were saying "Do an update". And his reply was "No. I've tried and the c++ compilers for epel7 can't do that".

So ... to me this doesn't sound like someone who doesn't want to take care of their packages and/or security updates. It's someone who's had multiple (and we see that it's multiple) people ask him to fix it, and they are tired of replying to the same question over and over again.

It sounds like he mis-understood what you are asking, and to be honest, I would have also with your initial comment. It sounded like you were saying "Do an update".

I'm not sure how anyone could interpret it that way. At no point did I ask for a new update. I asked for the maintainer to avoid such disruptive updates in the future, and if it is unavoidable to follow the documented process for that.

And his reply was "No. I've tried and the c++ compilers for epel7 can't do that".

His reply was that that he refuses to ask permission to "fix" the package (and by fix he means removing all files but leaving the empty package). Had this maintainer followed the incompatible process (which we expect all EPEL packagers to), I suspect we would have recommended retiring the package outright rather than shipping an empty package.

So ... to me this doesn't sound like someone who doesn't want to take care of their packages and/or security updates. It's someone who's had multiple (and we see that it's multiple) people ask him to fix it, and they are tired of replying to the same question over and over again.

When I saw the issue brought up in IRC, one of the first things I did was check the mailing list to see if it had been announced as an incompatible update. Following the process would have provided the desired notifications to reduce the amount of questions about this empty package. Furthermore, retiring the package outright would have prevented even more of those questions.

And his reply was "No. I've tried and the c++ compilers for epel7 can't do that".

His reply was that that he refuses to ask permission to "fix" the package (and by fix he means removing all files but leaving the empty package). Had this maintainer followed the incompatible process (which we expect all EPEL packagers to), I suspect we would have recommended retiring the package outright rather than shipping an empty package.

I don't think so. If you look at the CVE, it is a remote exploit. In other words, if you are running it, someone can get into your machine remotely. Removing the package would leave people running the bad software and allow people to get into their machine. By removing all the packages, you remove the service if they do an update. Then the only way they can run the service it to make an effort to run it.

We discussed this at the 2023-09-27 EPEL Steering Committee meeting.

https://meetbot.fedoraproject.org/fedora-meeting/2023-09-27/epel.2023-09-27-20.00.html

The issue in question was resolved with a new update that restores the removed files and updates the package to an upstream version that resolves the CVE.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a99c56df6a

For potential future escalations, we agreed that we'll defer to FESCo. An issue has been filed to address the current flaw in that process.

https://pagure.io/fesco/issue/3078

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/249

Please continue any further discussion there.