Bug details: https://bugzilla.redhat.com/show_bug.cgi?id=2177834 Information from BlockerBugs App: <img alt="2177834" src="https://qa.fedoraproject.org/blockerbugs/api/v0/bugimg/2177834" />
Commented but haven't voted yet: adamwill
The votes have been last counted at 2023-03-15 23:42 UTC and the last processed comment was #comment-847090
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)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
Using this criterion:
Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.
I think I'm
FinalBlocker +1
But I'm open to an argument that this is not a "typical configuration"
It seems by what the reporter said on ticket that the fix is working fine, good. By the criterion @bcotton commented:
Here, I am kind of inclining to -1, as VPN connection without any hardware based auth works.
FinalBlocker -1
but for sure FinalFE +1
yeah, this really comes down to whether we consider this a "typical" enough configuration. (It might be useful to know if it affects any other scenarios besides having the cert in a yubikey).
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F38 is no longer tracked by BlockerBugs, closing this ticket.
Login to comment on this ticket.