I should point out that there are also bugs regarding these CVE's:

https://bugzilla.redhat.com/show_bug.cgi?id=2054956
https://bugzilla.redhat.com/show_bug.cgi?id=2054957
https://bugzilla.redhat.com/show_bug.cgi?id=2054959
https://bugzilla.redhat.com/show_bug.cgi?id=2054960
https://bugzilla.redhat.com/show_bug.cgi?id=2054955
https://bugzilla.redhat.com/show_bug.cgi?id=2054973
https://bugzilla.redhat.com/show_bug.cgi?id=2054974
https://bugzilla.redhat.com/show_bug.cgi?id=2054979
https://bugzilla.redhat.com/show_bug.cgi?id=2054980
https://bugzilla.redhat.com/show_bug.cgi?id=2054958
https://bugzilla.redhat.com/show_bug.cgi?id=2054972
https://bugzilla.redhat.com/show_bug.cgi?id=2054978

I think this is fine, so...

+1

I don't have a problem exempting this package from the stable updates policy, but I wonder if it might not be a better long-term solution to package it as a Flatpak instead?

Anyway, +1 so as not to block the immediate solution.

+1

(I don't think flatpak vs. rpms matters here: the issue is that upstream updates with a faster cadence than we'd like and it is too hard to provide support for older releases. With flatpaks only the latest version would be supported, so users will have as much or even less choice than with rpms.)

Upstream no longer maintains 5.1.12, and I've unsuccessfully attempted to cherry pick the 6.0.2 fixes into 5.1.12.

These two facts taken together make this a clear +1 for me.

+1

So far, I've seen 5 positive votes and no negative votes here. That is encouraging.

Will there be a FESCo meeting on Tuesday? Will this issue get a final decision then?

I'm not trying to rush the process, but I'd naturally like to move forward as soon as I can.

There are multiple paths forward:

• If nothing special happens, and nobody votes against it, this ticket will be approved 7 days after it was created. If all 9 FESCo members vote +1, it is approved immediately, but that rarely ever happens.
• If you want to move forward quickly, we can tag this ticket with "fast track" -- that means if this gains +7 before anybody votes against it, it's approved immediately. This currently requires additional 2 positive votes and fallbacks to a full week if not received.
• Alternatively, we can tag this ticket with "meeting" to rubber-stamp it on Tuesday, however, there are no other meeting-tagged tickets, so I'd rather not ask ~9 people to sit down at the same moment just to approve this one.

I'm +1 to this case, but I would urge the maintainer to not just always update it, even if it's release cycle is off from fedoras. If there's serious bugs fixed then sure, but if not, letting stable release users use an old version for a few months would be better than always updating them in the middle of a stable release.

@churchyard - thanks for explaining the process. I hadn't known about the automatic 7 day approval period or fast track tags; I thought a formal meeting was needed. And I agree that forcing a meeting just for this issue is inappropriate.

Because the CVE's do represent some risk to users, and because there is no good way to make the users aware of the risk, perhaps the "fast track" tag is appropriate - we are currently 1 vote shy by my count.

@kevin - I understand and agree with your point. I won't use the exemption, should it be granted, unless there is a serious bug that cannot be dealt with any other way.

Has this been approved based on elapsed time with no negative votes? Can I proceed with the build?

Yes, it was. Yes, you can. Sorry for the delay.

APPROVED (+6,0,-0)

Thanks!

Normally, there is a 7 day delay between a build going into testing and then going into stable - we never get enough karma to shorten that.

Given that these builds are to address CVE's, should that interval be shortened, or should some other parameter be changed?

If so, since I've never done that before, would I specify the parameters when I do the "fedpkg update"?

That will not work. You can lower the karma limits and ask somebody to test it.

This is now announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WUNDVPZNIV3UK5HOQ4YXWBWOEQLIUJMC/

But still needs to be documented?

Blech, you're right.

I've opened a PR to document the exception. I'm not sure if that is my responsibility to merge, or if I even have that authorization. Anyway, here is the PR: https://pagure.io/fesco/fesco-docs/pull-request/60

Thanks.