Date: Fri, 20 May 2022 10:57:41 +0000 From: bugzilla-noreply@freebsd.org To: chromium@FreeBSD.org Subject: [Bug 263790] www/chromium: Unable to use FIDO U2F Message-ID: <bug-263790-28929-ObhWswptjP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263790-28929@https.bugs.freebsd.org/bugzilla/> References: <bug-263790-28929@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263790 Peter Jeremy <peterj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|www/chromium: Unable to |www/chromium: Unable to use |login to Google after |FIDO U2F |upgrade to 101.0.4951.54 | --- Comment #13 from Peter Jeremy <peterj@FreeBSD.org> --- I've tried disabling my Yubikey and using an alternative 2FA method and I c= an login to Google successfully. This is a regression because Chromium 99.x allowed me to choose a 2FA method whereas Chromium 100.x doesn't bring up t= he menu allowing me to choose an alternative. I've tried attempting to add a security key via Chromium. Working through,= it reaches a popup that just spins, with or without the key installed: " Add a security key You=E2=80=99ll see instructions in your browser window for adding your key = to your account " I do regularly use a security key with Chrome (on Linux) but don't have any non-FreeBSD systems that I can easily test Chromium on. I've tried using my security key to login to Github using Chromium on FreeB= SD and it also fails in a similar way: It spins waiting for the security key. = I'm not sure if this is a regression because I haven't tried it previously. I've tried doing some ktrace'ing and Chromium isn't attempting to even look= for a security key in either case: In my case, the security key appears as /dev/uhid1 but: * in the github login case, there are no accesses to /dev. * in the Google "add a key" case, only /dev/null and /dev/urandom are acces= sed. OTOH: * in both cases, there are a number of access attempts to /sys/class/input/event* - which might make sense on Linux, but not FreeBSD. * during a ktrace of Chromium starting, I did find an unsuccessful access attempt to /dev/fido - despite the name, that's actually the interface to watchdog(4). I couldn't find the code that does that. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263790-28929-ObhWswptjP>