I do not think this is a blocker. I have updated my Silverblue machine fully this morning and it still uses the 1.11.3 version, which works according to the bug report. This could come as 0-day update or as a an FE.

FinalBlocker -1
FinalFE +1

This definitely looks like something which should be included in the final release:

FinalFE +1

Lukas has a good point about the update status. 1.12.0 was never pushed stable, and 1.11.3 works. At the same time, 1.12.0 contains an important security fix:

In addition, this release fixes a security vulnerability in the portal
support. Some recently added syscalls were not blocked by the seccomp rules
which allowed the application to create sub-sandboxes which can confuse
the sandboxing verification mechanisms of the portal. This has been
fixed by extending the seccomp rules.
For details, see:
GHSA-67h7-w3jq-vh4q

which is then fixed again in 1.12.1:

The security fix in the 1.12.0 release failed when used with some
older versions of libseccomp (that don't know about the new syscalls).

So we can apply the following here:

The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation).
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Security_bugs

The CVE has a Base Score: 8.8 HIGH. I don't know how it translates to the Red Hat severity classification scale, but it seems wise to incorporate this in the final release:

FinalBlocker +1

The CVE has a Base Score: 8.8 HIGH. I don't know how it translates to the Red Hat severity classification scale, but it seems wise to incorporate this in the final release:

I looked into this pretty closely and despite the CVSS base score, I think the impact is just not high enough to be truly urgent. It's technically a sandbox escape, but it's quite limited and I haven't seen any specific examples of what can go wrong.

FinalBlocker -1

FinalFE +1

We need this FE as a workaround for a bodhi bug. Users who received the broken 1.12.0 update from updates-testing before it was unpushed are not receiving the 1.12.1 update via updates-testing because bodhi has decided to not submit this update to updates-testing. For further context, see this mailing list thread.

I looked into this pretty closely and despite the CVSS base score, I think the impact is just not high enough to be truly urgent. It's technically a sandbox escape, but it's quite limited and I haven't seen any specific examples of what can go wrong.

OK, thanks. I change my vote to
FinalBlocker 0

We need this FE as a workaround for a bodhi bug.

Beta testers should really make use of dnf distrosync instead of dnf update, otherwise they'll likely get into much worse trouble than a pending flatpak update. I'm not saying the Bodhi behavior is great, but we should really stress that beta (or updates-testing) testers must use distrosync periodically, that's the only way to synchronize with the unpushed updates.

Beta testers should really make use of dnf distrosync instead of dnf update, otherwise they'll likely get into much worse trouble than a pending flatpak update. I'm not saying the Bodhi behavior is great, but we should really stress that beta (or updates-testing) testers must use distrosync periodically, that's the only way to synchronize with the unpushed updates.

We have a problem then, because GNOME Software does not distro-sync (except for the distro upgrade itself), and I don't update manually with dnf. I don't think beta testers should be expected to do anything special.

FinalFE +1
AGREED AcceptedFinalFE

The following votes have been closed:

• Accepted FinalFreezeException (+4, 0, -0)
  • +1 by lruzicka, kparal, catanzaro, adamwill

Note: there is already a flatpak 1.12.2. Might as well get that in under the auspices of this FE.

Note: there is already a flatpak 1.12.2. Might as well get that in under the auspices of this FE.

pinging @adamwill , I think it'll be best to create a new FE request as the 1.12.1 is already on its way to stable?

Or, if you create (or somebody else) creates a new bodhi update, it should get edited and 1.12.1 stable push stopped if I am not mistaken.

We have a problem then, because GNOME Software does not distro-sync (except for the distro upgrade itself), and I don't update manually with dnf. I don't think beta testers should be expected to do anything special.

Well, the only "solution" to that problem is never to have updates-testing enabled by default :-) But I disagree with your premise. Testing unstable software is not for everyone, and those who participate should have extra knowledge (bug reporting, system repair, etc), otherwise both sides will get unhappy pretty soon. And yes, the current state is that testers (pre-release, updates-testing for stable release, etc) mustn't rely on gnome-software only, otherwise their systems will end up in an inconsistent state, quite regularly.

Release F35 is no longer tracked by BlockerBugs, closing this ticket.