User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

This is on FreeBSD version 13.1-RELEASE-p7, using a Nitrokey 3. Other user report issue with Yubikeys.

cd into third_party/rust/authenticator

cargo build --example main

(you may need to install some dependency that are available with pkg)

and then insert the security key

Finally,
RUST_LOG=debug cargo run --example main

Note that this seems to be more general to the usb subsystem, since it is also affecting webcam. For the version 111.0 rc1, authenticator-rs seems to work alone. But when trying to use it via the web browser, it get stuck. (when it is stuck, the security device is not usable until firefox is killed).

Actual results:

It timeout waiting to find the device and output:

[2023-03-14T21:39:29Z DEBUG authenticator::authenticatorservice] register called with 1 transports, iterable is 1
[2023-03-14T21:39:29Z DEBUG authenticator::authenticatorservice] register transports_to_cancel 0
[2023-03-14T21:39:29Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid3
[2023-03-14T21:39:29Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid2
[2023-03-14T21:39:29Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid0
[2023-03-14T21:39:29Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid1
[2023-03-14T21:39:29Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid3"
[2023-03-14T21:39:29Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid2"
[2023-03-14T21:39:29Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid0"
[2023-03-14T21:39:29Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid1"

Expected results:

It should find the device (here a part of the output when it works)

[2023-03-14T21:40:27Z DEBUG authenticator::authenticatorservice] register called with 1 transports, iterable is 1
[2023-03-14T21:40:27Z DEBUG authenticator::authenticatorservice] register transports_to_cancel 0
[2023-03-14T21:40:27Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid3
[2023-03-14T21:40:27Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid2
[2023-03-14T21:40:27Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid0
[2023-03-14T21:40:27Z DEBUG authenticator::transport::platform::monitor] Adding device /dev/uhid1
[2023-03-14T21:40:27Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid3"
[2023-03-14T21:40:27Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid2"
[2023-03-14T21:40:27Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid0"
[2023-03-14T21:40:27Z DEBUG authenticator::transport::device_selector] Device added event: "/dev/uhid1"
[2023-03-14T21:40:27Z DEBUG authenticator::transport::platform::device] device timeout 0
[2023-03-14T21:40:27Z INFO authenticator::transport::platform::device] new device "/dev/uhid1"
STATUS: device available: Vendor: Unknown Vendor, Device: Unknown Device, Interface: 2, Firmware: v1.0.2, Capabilities: 05

We have a patch for this upstream https://github.com/mozilla/authenticator-rs/pull/238, which we'll get into Firefox 113. I'll look into whether we can backport something to 112.

Is CTAP2 enabled in FreeBSD Firefox 111? Is that something Thibault individually enabled? Or does this bug hit us even if the CTAP2 pref is not enabled?

This affects the CTAP1 implementation as well.

(In reply to Daniel Veditz [:dveditz] from comment #2)

Is CTAP2 enabled in FreeBSD Firefox 111? Is that something Thibault individually enabled? Or does this bug hit us even if the CTAP2 pref is not enabled?

I don't recall if it is enabled by default, but I did tried changing this preference with the same result.
As for testing it was only CTAP1 implementation (the u2f that only require user presence, no pin entry).

A patch for this is available in Nightly. Thibault, could you help us test it?

(In reply to John Schanck [:jschanck] from comment #5)

A patch for this is available in Nightly. Thibault, could you help us test it?

I can confirm that it works after merging https://github.com/mozilla/authenticator-rs/pull/238 .

What works is the ctap1 implementation, attempting to enable ctap2 will not work (on the demo yubico sites, but I don't known if it supposed to work with ctap2).

I will test 112 rc1 as soon as it is built (it was update in the port tree on april 3rd, so I guess in less than a week it should be available in FreeBSD pkg repositories).

For nightly, it will be complicated to test. I don't know how the port manage to generate all the webrtc patches (it seems to be automated, but I don't know where is the script that do that)

I can confirm that it works after merging https://github.com/mozilla/authenticator-rs/pull/238 .

Thanks, that's enough for me to consider this bug fixed.

As for CTAP2, it could be an issue with our support for the Nitrokey 3. Could you try cargo run --example ctap2 on the ctap2-2021 branch of authenticator-rs? If that does not work, please open an issue with authenticator-rs on github.