Created attachment 871144 [details]
step1

Created attachment 871145 [details]
step2

Created attachment 871146 [details]
step3

I can't reproduce this on SLES (which is the same binary).

Therefore, a couple of questions:
1. Just to be sure: It's not flatpak, right?
2. Which Thunderbird version are you using?
3. Have you tried plugging the key out and back in again, while you are being prompted for it?
4. Can you reproduce the bug with the upstream tarball?
5. Please start TB from the commandline with `RUST_LOG=authenticator=debug thunderbird`

Thanks!

1) 2) MozillaThunderbird-115.5.0-150200.8.139.1.x86_64
3) yes
4) What would be the 'upstream' these days? Mozilla offers Firefox, Pocket, Mozilla VPN .. but not Thunderbird?

5)

 RUST_LOG=authenticator=debug thunderbird |& tee thunderbird.log
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
[INFO  authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw0")): Permission denied (os error 13)
[INFO  authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw4")): Permission denied (os error 13)
[INFO  authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw1")): Permission denied (os error 13)
[INFO  authenticator::statemachine] error happened with device: Error: requested operation is not available on device
[INFO  authenticator::transport::platform::device] new device "/dev/hidraw3"
[INFO  authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw7")): Permission denied (os error 13)
[INFO  authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw8")): Permission denied (os error 13)
[INFO  authenticator::statemachine] error happened with device: Error: requested operation is not available on device
[INFO  authenticator::statemachine] error happened with device: Error: requested operation is not available on device
[INFO  authenticator::statemachine] Device "/dev/hidraw3" continues with the signing process
[INFO  authenticator::statemachine] PIN Error that requires user interaction detected. Sending it back and waiting for a reply
[INFO  authenticator::statemachine] Statemachine was cancelled. Cancelling transaction now.
[INFO  authenticator::transport::platform::transaction] Transaction was cancelled.

Thanks!

4.) https://www.thunderbird.net/

5.) Ok, I think I may see the problem. I'll have to verify it, but it seems your hardware token is PIN protected and maybe Thunderbird can't open the PIN-dialog and thus 'everybody' is waiting until the timeout hits.

As a workaround, you could try to open about:config ("Config editor" in the settings search) and deactivate `security.webauthn.ctap2` for now.
And/Or try a second hardware token, if you have, without a PIN.

Yes. looks like Thunderbird is asking /dev/null for a PIN.

It will, of course, not work without one.

It correctly detects that it needs one.

Okta insists on one. In fact it registered the key without one initially and then re-registered with PIN.

> 4.) https://www.thunderbird.net/

Does the same, except it stores the profile in a different location and needs to be set up again

> As a workaround, you could try to open about:config ("Config editor" in the settings search) and deactivate `security.webauthn.ctap2` for now.

This works, btw.
I just tested this by adding a token with PIN-protection to Okta, flipped this config in Thunderbird and could log in.
Unless your hardware key does not support FIDO1 (which almost all do), you should be able to use it like this for now.
(Yes, one can bypass the PIN-protection this way. Yes, this is how the spec was designed. Don't blame me, I wasn't involved.)

This needs an upstream bugreport, though. Thunderbird should be able to display the PIN-dialog.

Indeed, the specification does not have to make sense.