Bug 270092 - www/firefox: Cannot use webauth since 111.0
Summary: www/firefox: Cannot use webauth since 111.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Christoph Moench-Tegeder
URL:
Keywords:
: 266317 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-03-10 17:07 UTC by Thibault Payet
Modified: 2023-04-23 09:16 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (gecko)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thibault Payet 2023-03-10 17:07:42 UTC
Since the upgrade to 111.0, webauth is completly broken.

After asking for user presence, the security key is not accessible until firefox is killed. And the key never blink.

I only have a Nitrokey 3 security key, so I don't know if it applies to other.

I have verified that the key is still working (doing webauth u2f using a smartphone work).
Comment 1 Nathan Whitehorn freebsd_committer freebsd_triage 2023-03-14 14:11:53 UTC
This also affects Yubikeys at least. When Firefox tries to use the device, it also locks out other uses of the device until Firefox is killed, so it seems to be some aspect of its interaction with the USB system.
Comment 2 Thibault Payet 2023-03-14 21:44:18 UTC
It seems that it is related to authenticator-rs
in third_party/rust/authenticator

The version went from 0.4.0-alpha.6 to 0.4.0-alpha.9

When using the version from 110, no issue the registration process works.
When using the version from 111, it stop at

[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"

Comparatively

[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
Comment 3 Thibault Payet 2023-03-14 22:30:41 UTC
So, if we look only at authenticator-rs here are my result:
for the version of firefox:

110.0.1_2 -> no issue
111.0 -> no issue
111.0_1 -> stuck in finding the device

But when u2f is attempted in firefox, it does not work for the version: 111.0 and 111.0_1 .
Comment 4 Dave Cottlehuber freebsd_committer freebsd_triage 2023-03-15 20:25:10 UTC
ditto for yubikey and solokey too here. It completely borks USB and I need to power cycle the box.
Comment 5 Dave Cottlehuber freebsd_committer freebsd_triage 2023-03-15 20:27:28 UTC
Thibault thats very useful info. Perhaps you can share how you debugged this
and how we could revert the authenticator-rs if needed?
Comment 6 Thibault Payet 2023-03-15 22:31:07 UTC
(In reply to Dave Cottlehuber from comment #5)
Thanks, here the steps:
In the directory (from firefox extracted directory from port)
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

Since authentificator-rs that came from firefox 111.0 seems to works, I am not sure that only reverting the update to authentificator-rs is sufficient.

So likely there is multiple issues (since for 111.0_1 even authentificator-rs alone does not work).
Comment 7 Dave Cottlehuber freebsd_committer freebsd_triage 2023-03-16 10:39:41 UTC
firefox-esr works, if you run `MOZ_ALLOW_DOWNGRADE=1 firefox` to accommodate
different profile versions. YMMV.

Version        : 102.9.0_1,1
Installed on   : Thu Mar 16 08:42:15 2023 UTC

I have also had problems with videoconference (video but not audio recording) so
this may be a more general USB-related problem here, which is also addressed by reverting to ESR.
Comment 8 Graham Perrin freebsd_committer freebsd_triage 2023-03-23 23:58:51 UTC
> 1824066 - authenticator-rs does not work since firefox 111.0 rc2

Thanks to Thibault for the upstream report and cross-reference here. 

The upstream pull request is merged. 

----

Triage: whilst not assigned, here, to an individual, it seems reasonable to treat the report as in progress.
Comment 9 commit-hook freebsd_committer freebsd_triage 2023-03-24 21:24:58 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=388dd4e9e29324b86c19d656b5523013daa1837f

commit 388dd4e9e29324b86c19d656b5523013daa1837f
Author:     Christoph Moench-Tegeder <cmt@FreeBSD.org>
AuthorDate: 2023-03-24 21:23:18 +0000
Commit:     Christoph Moench-Tegeder <cmt@FreeBSD.org>
CommitDate: 2023-03-24 21:23:18 +0000

    www/firefox: Restore webauth/security key usage

    patch from upstream authenticator-rs
    https://github.com/mozilla/authenticator-rs/pull/238

    PR:             270092
    Reported By:    Thibault Payet

 www/firefox/Makefile                     |  2 +-
 www/firefox/files/patch-bug1824066 (new) | 37 ++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletion(-)
Comment 10 commit-hook freebsd_committer freebsd_triage 2023-03-24 21:30:01 UTC
A commit in branch 2023Q1 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=376ed2486ab8224c6290e897f53c5360aa9fff92

commit 376ed2486ab8224c6290e897f53c5360aa9fff92
Author:     Christoph Moench-Tegeder <cmt@FreeBSD.org>
AuthorDate: 2023-03-24 21:23:18 +0000
Commit:     Christoph Moench-Tegeder <cmt@FreeBSD.org>
CommitDate: 2023-03-24 21:29:11 +0000

    www/firefox: Restore webauth/security key usage

    patch from upstream authenticator-rs
    https://github.com/mozilla/authenticator-rs/pull/238

    PR:             270092
    Reported By:    Thibault Payet

    (cherry picked from commit 388dd4e9e29324b86c19d656b5523013daa1837f)

 www/firefox/Makefile                     |  2 +-
 www/firefox/files/patch-bug1824066 (new) | 37 ++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletion(-)
Comment 11 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2023-03-24 21:32:11 UTC
imported upstream fix, seems to be fine.
Comment 12 Graham Perrin freebsd_committer freebsd_triage 2023-04-23 09:16:27 UTC
*** Bug 266317 has been marked as a duplicate of this bug. ***