Discussed during the 2021-03-29 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as this seems serious, but benzea believes it's the same as #1933520 and should have been fixed already. If it is not, we need to figure out under what circumstances that fix isn't working before we can decide if the impact is wide enough to be a blocker.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-29/f34-blocker-review.2021-03-29-16.00.txt

Given comments 19 and 20, it looks like a local configuration issue.
FinalBlocker -1

FinalBlocker -1

@chrismurphy it's not as simple as "local configuration issue". It's more "attempt to fix this does not work in some perfectly legitimate scenarios, like an old install that's been continually upgraded, or an install where the local config was changed outside of authselect in any way at all".

IMO the problem here is that the local config was somehow changed outside of authselect. That might be a Fedora bug, or it might be the user modifying files manually. Regardless, it should never happen. Once it has happened, we are stuck in a state where manual intervention is required to recover.

In that case I'm finalblocker 0, and need more info what the scope of the problem is. If there are cases coming from clean install of Fedora 32+ then I'm inclined to block. If these are older installations that have been upgraded, then I'm inclined to not block and instead recommend a clean install.

AGREED RejectedFinalBlocker
AGREED AcceptedFinalFE

Discussed during the 2021-04-05 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" and an "AcceptedFreezeException (Final)" was made as the consensus was that it's just too narrow in scope to see as a release blocker (we believe it affects systems that started as Fedora 27 or earlier, and systems where nsswitch configuration was changed outside of authselect). It is accepted as a freeze exception.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-04-05/f34-blocker-review.2021-04-05-16.02.txt

The following votes have been closed:

• Rejected FinalBlocker (+0, 0, -2)
  • -1 by chrismurphy, catanzaro
• Accepted FinalFreezeException (+0, 0, -0)

Resetting FinalBlocker per https://bugzilla.redhat.com/show_bug.cgi?id=1942443#c41

REVOTE FinalBlocker

Given the new information, I am sad to report that I'm

FinalBlocker +1

If this really does affect almost all upgrades, then yeah...

FinalBlocker +1

Hmmm, it seems its going to affect lot of users

FinalBlocker +1

FinalBlocker +1

Sigh, I wanted to release next week, but I agree we should fix this first. This issue cannot be addressed with a system update because affected users will be unable to log in to apply the update.

FinalBlocker +1

I'm slightly confused by this. Is everyone voting to just fix the fingerprint issue? In that case we can close the bug, the update got already pushed stable (even though some verification would be nice, I'll try).
Or are people voting for a fix that would reset all authconfig files for people as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1942443#c51 (and I started talking about it in comment 42)?

I think people are voting on the belief the recent discussion means there are still real world cases unfixed by the current update. Is that not correct?

In any case, it seems to me that this could at least be a 0day, since it's an upgrade issue.

I'm slightly confused by this. Is everyone voting to just fix the fingerprint issue? In that case we can close the bug, the update got already pushed stable (even though some verification would be nice, I'll try).

If users can log in, then IMO that is sufficient. The blocker designation is because Fedora is effectively totally busted if you cannot log in to your user account.

Or are people voting for a fix that would reset all authconfig files for people as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1942443#c51 (and I started talking about it in comment 42)?

That seems like the most robust way to fix this issue, but surely it's not required to resolve the blocker issue.

In any case, it seems to me that this could at least be a 0day, since it's an upgrade issue.

Yes, this does not need to be fixed on install media, so it should be a 0day blocker.

Sigh, I wanted to release next week, but I agree we should fix this first. This issue cannot be addressed with a system update because affected users will be unable to log in to apply the update.

So that was incorrect. It can be fixed with an update. We just need to make sure the update is ready.

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