[snap] U2f yubikey not recognized until unplugged and plugged back in

Thank you for your bug report. When did it stop working? Was there any update around the time? Could you give some details on how you setup and use the yubikey there?

I use it only for github, no special setup was needed (udev rules are already there for PIV). I logged last time some months ago so I don't know when it stopped working exactly.

Tested firefox snap - u2f works.

Can you run chromium with the following command, and share the output after a failed attempt to use U2F to log in to github?

    snap run chromium --enable-logging=stderr --v=1

Log attached. Relevant line probably

[92777:92906:0709/115647.054273:ERROR:udev_watcher.cc(96)] Failed to begin udev enumeration.

Sorry for the lack of feedback Alexey.

I have just tested with my Yubikey 4, using https://demo.yubico.com/playground, and U2F appears to work as expected.

Are you still seeing the problem with the latest chromium snap?

Still not working. And right link to test is https://demo.yubico.com/webauthn-technical/registration

name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical*
contact: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
  An open-source browser project that aims to build a safer, faster, and more
  stable way for all Internet users to experience the web.
commands:
  - chromium.chromedriver
  - chromium
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: 12 days ago, at 19:18 MSK
installed: 84.0.4147.89 (1229) 166MB -

Can you share the last few lines of `dmesg` after plugging in your yubikey, to get more information about the device?

Funny thing. I have Yubikey 5C Nano and it is hard to get out of port. So I plugged spare Yubikey 4 to get dmesg lines and it worked with chromium. Then I replugged my yubikey 5c nano and it worked too. Then I rebooted without unplugging yubikey and it not working in chromium again but works in firefox.

The plot thickens. Can you reliably reproduce this situation, where unplugging and plugging again the 5C makes it work, but it doesn't after a reboot?

Sorry for long delay. No I can't reproduce it anymore in a way I described before, but it still happens to me. For now certain is that repluging yubikey fixes the problem, reboot doesn't.
Upgrading the snap most probably triggering it, need to test it more times.

Hm, now I updated chrome to 84.0.4147.105 (1260) and can reproduce it reliably by inserting yubikey and then starting chromium with new profile (chromium --user-data-dir=./111).

For now I can send udev event instead of replugging:

ls -l /sys/class/hidraw/ | grep :1050: | awk -F/ '{print $NF}' | xargs -r -L1 -I T udevadm trigger -c add --name-match=T

Status changed to 'Confirmed' because the bug affects multiple users.

Same problem here. Here are my observations, which match the behavior already described.

- To reproduce: Insert YubiKey, start Chromium, attempt login (nothing happens when tapping on YubiKey), replug YubiKey, attempt login (now it works).
- It works when done in this order: Start Chromium, go to 2FA login page (where Chromium asks user to tap on YubiKey), plug in YubiKey, confirm login (by tapping on YubiKey).
- Emitting the udev event instead of replugging works too.
- It seems to be important that Chromium already attempted to use YubiKey before YubiKey is actually plugged in. (Inserting YubiKey after Chromium is started but 2FA login page has not yet been visited gives the same result as when YubiKey is inserted before Chromium is started.)
- After first login it works reliably until Chromium is restarted.
- After installing Ubuntu 20.10 (clean install) I could not reproduce the problem for a few days, then it broke again. There was an update of the Chromium snap at this time, I suspect that that is what broke it again.
- dmesg shows several apparmor denied messages when accessing a site that attempts to use YubiKey:

[Sun Nov 22 10:10:11 2020] audit: type=1400 audit(1606036212.912:264): apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/run/udev/data/+thunderbolt:domain0" pid=45717 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[Sun Nov 22 10:10:11 2020] audit: type=1400 audit(1606036212.912:265): apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/run/udev/data/+thunderbolt:0-0" pid=45717 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[Sun Nov 22 10:10:11 2020] audit: type=1400 audit(1606036212.912:266): apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/run/udev/data/+thunderbolt:0-101" pid=45717 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[Sun Nov 22 10:10:11 2020] audit: type=1400 audit(1606036212.912:267): apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/run/udev/data/+thunderbolt:0-1" pid=45717 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[Sun Nov 22 10:10:11 2020] audit: type=1400 audit(1606036212.968:268): apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/run/udev/data/c511:0" pid=45717 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

The issue still exists. A workaround, proposed by @baz-irc above works for me as well.

My configuration: Ubuntu 22.04, Linux kernel 6.2.0, chromium 113.0.5672.126

Issue still present in Ubuntu 22.04.02 with Yubikey 5C Nano and the workaround does not seem to work for me