#981 [gnome-control-center] Settings crashes when trying to edit WPA2 Enterprise wifi without a stored password | rhbz#2136471
Closed a year ago by blockerbot. Opened a year ago by blockerbot.

Bug details: https://bugzilla.redhat.com/show_bug.cgi?id=2136471
Information from BlockerBugs App:
2136471

Current vote summary

Commented but haven't voted yet: mattdm, coremodule

The votes have been last counted at 2022-10-24 16:22 UTC and the last processed comment was #comment-822636

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


It sounds from the GNOME bug that

  • this doesn't occur during the first configuration, and
  • if it is already configured and you don't need to edit it, it continues to work

Is that correct? If so, I see some wiggle room for not blocking (and hopefully having a zero-day update). If one can't make this type of connection on a new install, or continue using what was already working on an upgrade, I lean heavily to blocking.

Both are correct. If you configure it correctly on the first try, it will work and you can continue using it. Upgrades also shouln't be a problem. But if you misconfigure something during your first configuration, or need to change the username or similar, you can't edit it and fix it. You can't even remove it and create it again.

While it affects most of us employed at IT companies, I think it's still somewhat a niche use case. And it seem to have been broken for half a year. That suggests that documenting it and hopefully fixing it soon is probably a sufficient solution.

@kparal this was already at f36? That's it?

The fact that it's been broken for a while and folks seem to mostly be fine suggests that it's conditional enough to not block on.

FinalBlocker -1
FinalFE +1

While it affects most of us employed at IT companies, I think it's still somewhat a niche use case.

Not really. If you've ever been to a school, for instance, that's probably WPE2-Enterprise.

So this was a tough call for me. Although very annoying, there are definitely going to be easy workarounds: you can use nm-cli to undo anything you do in the GUI settings, after all. Since it's only conditionally broken and not 100% broken, I feel like this is the sort of thing that we could fix in a post-release update, and therefore not quite enough to fall under basic functionality failure. Except if we don't fix this, users are not going to be able search for workarounds or apply those post-release updates, because they won't be able to connect to the internet. And I suppose that tips the scales on this for me, even though it's gone unnoticed for a relatively long time.

FinalBlocker +1

All that said, I would nevertheless waive it under the late blocker policy for being proposed way too late. That's a separate step that comes later, though.

In particular, Kamil says:

You can't even remove it and create it again.

A reasonable user would probably give up at that point.

This is clearly a blocker to me, but I could be convinced to waive it, because it can be worked around with a guidance at least. We have some time now to try and fix it.

FinalBlocker +1

Not really. If you've ever been to a school, for instance, that's probably WPE2-Enterprise.

Please note, that this doesn't happen happen for all WPA2-Enterprise networks. Only for those where the password is not remembered, i.e. you fill it out every time. The most common scenario is 2FA login, which is unlikely to happen in a school environment.

Hmm, that's a good point...

I'm at least:
FinalFE +1
I'm gonna count everyone who's blocker +1 as FE +1, and accept this at least as FE for now while the blocker vote isn't totally clear. This is so we can pull in a fix for this when we do a compose, since we now have the kernel fix.
AGREED AcceptedFinalFE

The following votes have been closed:

FinalBlocker -1

FinalFE +1

Reading the comments from catanzaro I think that a standard user should be able to get updates and have a working internet connection by wifi even if they enter a wrong password or other data at the first time. So we should make sure that the fix is in the release media.

FinalBlocker +1

I think the enterprise wifi + not stored password it niche enough use case to not block the release on it.

FinalBlocker -1

I think the enterprise wifi + not stored password it niche enough use case to not block the release on it.

I think enterprise wifi is used on nearly all universities, companies, etc. And it is not unusual that someone misspells a password.

I think enterprise wifi is used on nearly all universities, companies, etc. And it is not unusual that someone misspells a password.

Yes, but that use case isn't broken. It's only broken if it's saved without any password at all, i.e. "ask every time".

Things exposed by the settings app should work, especially ones that may prevent you from updating and getting the fix post release. I'm uncomfortable speculating on how common a use case is (even if it has apparently been broken for 6+ months, which probably gives us a pretty big clue). I see it as a blocker, but I would understand if it got waived conditionally.

FinalBlocker +1

AGREED AcceptedFinalBlocker

Discussed during the 2022-10-24 blocker review meeting:

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as, while there's some disagreement, there's a majority of 3 for accepting this as a violation of the "basic functionality" requirement for the control center.

The following votes have been closed:

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

a year ago

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

Login to comment on this ticket.

Metadata