Hello, I have www/chromium 39.0.2171.95_3 installed from the binary package (tried compiling it myself, but the result was the same) and it segfaults when I try to login using an account which uses a security key (Yubico Nano). While I didn't expect support for the Yubico device to work right away, the segfault was a surprise. The problem occurs even when the security key is not inserted. Logging in with an account which does not use a security key works fine. I'm rebuilding chrome now with debug option, so the core file makes more sense. From truss: stat("/usr/share/nls/en_US.UTF-8/libc.cat",0x7fffffffdf48) ERR#2 'No such file or directory' stat("/usr/share/nls/libc/en_US.UTF-8",0x7fffffffdf48) ERR#2 'No such file or directory' stat("/usr/local/share/nls/en_US.UTF-8/libc.cat",0x7fffffffdf48) ERR#2 'No such file or directory' stat("/usr/local/share/nls/libc/en_US.UTF-8",0x7fffffffdf48) ERR#2 'No such file or directory' Segmentation fault (core dumped) write(2,"Segmentation fault (core dumped)"...,33) = 33 (0x21) read(10,0x623330,1024) = 0 (0x0) process exit, rval = 139 (I've already manually build libc.cat and it's independent from this issue). From chrome_debug.log: [14507:396322816:0115/114800:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114800:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114801:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114801:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114801:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114801:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114801:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114814:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114843:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114843:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue [14507:396322816:0115/114843:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue Thanks
Auto-assigned to maintainer chromium@FreeBSD.org
Unfortunately, I cannot get www/chromium to work with the debug option enabled. I found some previous posts which refer to this issue, but no open bug, so I'll open a new one for that issue.
I have the same problem. I have this result with dtrace: sudo dtrace -n 'pid$target::strcmp:entry{printf("strcmp: called in %s module, arg0 = %lx, arg1 = %lx\n", probemod, arg0, arg1);}' -c "su ja -c chrome" [...] [90931:341516288:0211/210403:ERROR:net_util_posix.cc(281)] Not implemented reached in bool net::GetNetworkList(NetworkInt*, int) Segmentation fault (core dumped) dtrace: pid 90928 exited with status 139 Regards
(In reply to ja from comment #3) ATTENTION: default value of option force_s3tc_enable overridden by environment. [82707:341520384:0213/205610:ERROR:cache_creator.cc(133)] Unable to create cache [82707:341520384:0213/205610:ERROR:appcache_storage_impl.cc(1826)] Failed to open the appcache diskcache. [82707:341516288:0213/205619:ERROR:net_util_posix.cc(281)] Not implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, int) Segmentation fault (core dumped)
Hi, Is this problem still present? Thanks
Unfortunately, yes. Or at least something very similar: when I even try to register an U2F device with github, chromium crashed (for reference, that's chromium-47.0.2526.106 now).
(In reply to Christoph Moench-Tegeder from comment #6) Hi Christoph, Thanks for the update.
(In reply to Martin Wilke from comment #5) Yes, Chromium 48.0.2564.116
Still present in 49.0.2623.112_1 using pkg & 11.0-alpha1 on amd64. If you have a tab with 2FA request open (like github & many others) then it's impossible to recover the crashed session.
Still crashes for example when I try to log into github, as it sees Chromium and doesn't even give me the option for SMS as 2FA but wants to talk straight to my Security Key. This sucks. Do the Chromium/FreeBSD folks maybe need some hardware to reproduce this better? If you're interested, please contact me privately with your shipping address. thanks! % google-chrome --user-data-dir=/tmp/chrome-clean [54475:379686144:0101/101152:ERROR:linux_util.cc(122)] Not implemented reached in std::string base::GetLinuxDistro() [54475:379674624:0101/101152:ERROR:battery_status_manager_default.cc(25)] Not implemented reached in virtual bool device::(anonymous namespace)::BatteryStatusManagerDefault::StartListeningBatteryChange() libpng warning: iCCP: known incorrect sRGB profile [54508:379674624:0101/101206:ERROR:PlatformKeyboardEvent.cpp(84)] Not implemented reached in static bool blink::PlatformKeyboardEvent::currentCapsLockState() [1] 54475 segmentation fault google-chrome --user-data-dir=/tmp/chrome-clean
*** Bug 219098 has been marked as a duplicate of this bug. ***
Created attachment 183157 [details] patch Remove the NOTIMPLEMENTED() call in KeyboardEventManager::currentCapsLockState() only used for Mac password fields. See https://bugs.chromium.org/p/chromium/issues/detail?id=618739
Taking a look at U2F dependencies [1] Deps = [ "//base", "//crypto", "//device/base", "//device/hidden", "//net", ] more work is needed to solve this problem. [1] https://codesearch.chromium.org/chromium/src/device/u2f/BUILD.gn?l=31
(In reply to Carlos J. Puga Medina from comment #13) Fix copy-paste s/hidden/hid
*** Bug 222366 has been marked as a duplicate of this bug. ***
Not sure if this is helpful but iridium, another chromium derivative has similar issues: - www/iridium 58.0_8 crashes for the same reason - www/iridium 58.0_7 doesn't crash during login I'll report this upstream and keep you posted.
chromium crashes in extensions/browser/api/hid/hid_device_manager.cc::HidDeviceManager::LazyInitialize because after the chain of calls HidService::Create returns nullptr for FreeBSD. Is anybody working on this issue? Or should I look further?
(In reply to Oleksandr Tymoshenko from comment #17) Oleksandr, please, go ahead. Drop me a line if you need some help.
Created attachment 187829 [details] FreeBSD UHID service stub implementation This is dummy freeBSD UHID service implementation. It fixes crash but doesn't add any new functionality. I'm looking into what it's going to take to implement U2F HID support but no significant progress yet, there is no obvious "fit all use cases" API I can see. libusb provides hotplug/enumerate support but requires low-level HID implementation. And uhid(4) API does not provide access to vendor/product ids or hotplug events. Hotplug and vid/pid can be obtained by using devd but then it leaves the problem of enumerating devices that are already connected when chrome starts.
(In reply to Oleksandr Tymoshenko from comment #19) I've been working on FreeBSD support in u2f-hid-rs, the Rust library that's used in Firefox: https://github.com/myfreeweb/u2f-hid-rs/commit/85d86018ddbd3e6eb213f98397b93e0b04f62e55 Using devd for hotplug, and enumerating existing devices is essentially `ls /dev | grep uhid` :D There's no need to get VID/PID to check whether it's a U2F device! That would actually make new devices unsupported by default. That library just reads the HID report descriptor and checks for the FIDO usage: https://github.com/jcjones/u2f-hid-rs/blob/368c327ec787e02d93468e5f2574ebec30388cee/src/linux/hidraw.rs#L183-L219
(In reply to Greg V from comment #20) Hi Greg, Yes, you're right, VID/PID is not a strict requirement for U2F but Chromium uses its chrome.uhid API (https://developer.chrome.com/apps/hid) for platform-specific access to UHID devices. For U2F implementation it's not critical but I'd prefer to have fully functional API. Still, looks like it can't be helped.
Created attachment 188231 [details] chrome.hid implementation for FreeBSD attached patch implements enough of chrome.hid API to make U2F functional on FreeBSD. I tested my Yubico's U2F key both on GitHub and Yubico's demo app, seems to work. One of the requirements is that /dev/uhidX files should be readable/writable to the user who runs chrome. I fixed this by adding devd config (not quite secure) for Yubi's devices: % cat /usr/local/etc/devd/yubi.conf attach 20 { match "vendor" "0x1050"; action "/bin/chmod 766 /dev/$device-name"; }; Less blunt approach would be to create group and run chgrp in addition to chmod or just run chown instead of chmod. If there is better approach I'm not aware of it.
(In reply to Oleksandr Tymoshenko from comment #22) nice, thanks for the patch! I'll try it soon. Re: devd, libu2f-host installs /usr/local/etc/devd/u2f.conf.sample. But it's slightly wrong (it only works on /dev/usb/*, doesn't touch /dev/uhid*). What do you think about a separate port that creates the u2f group and installs a /usr/local/etc/devd/u2f.conf (not sample) that does both? And libu2f-host, chromium, firefox will all depend on it.
+1 for the port - excellent idea
Created attachment 188273 [details] u2f-devd port Here's the u2f-devd port. I hope it doesn't have to be GPL licensed :D (libu2f-host is, and technically that file was originally made there… it's a trivial config file that's mostly vendor/device IDs, not actual code…)
A commit references this bug: Author: gonzo Date: Mon Dec 4 05:44:25 UTC 2017 New revision: 455495 URL: https://svnweb.freebsd.org/changeset/ports/455495 Log: www/chromium: add support for USB U2F devices Implement enough of chrome.hid API to make U2F security keys work. Due to FreeBSD's HID API limitations it's not possible to consistently report vedor id or product id values for HID devices so if javascript library relies on this information to detect supported keys it won't work, only report descriptor based detection works. Also by default uhid(4) devices accessible only to root user, current solution is to change /dev/uhidX node permission using devd. For example create /usr/local/etc/devd/yubi.conf with following content and restart devd: attach 20 { match "vendor" "0x1050"; action "/bin/chmod 766 /dev/$device-name"; }; Work on u2f-devd port is in progress (see PR). When done it will take care of maintaining devd rulesets for U2F devices. PR: 196754 Approved by: cpm Changes: head/www/chromium/Makefile head/www/chromium/files/patch-device_hid_BUILD.gn head/www/chromium/files/patch-device_hid_hid__connection__freebsd.cc head/www/chromium/files/patch-device_hid_hid__connection__freebsd.h head/www/chromium/files/patch-device_hid_hid__device__info__freebsd.cc head/www/chromium/files/patch-device_hid_hid__device__info__freebsd.h head/www/chromium/files/patch-device_hid_hid__service.cc head/www/chromium/files/patch-device_hid_hid__service__freebsd.cc head/www/chromium/files/patch-device_hid_hid__service__freebsd.h
Created attachment 188626 [details] u2f-ports I prepared the svn diff to be committed into the ports tree. security/u2f-devd - Cosmetic fixes - Pet portlint warning @Greg, would you mind approving these changes? Thanks for working on it!
Comment on attachment 188626 [details] u2f-ports yeah of course
(In reply to Greg V from comment #28) Please, file a new PR to add the new port security/u2f-devd. I'll take care :)
(In reply to Carlos J. Puga Medina from comment #29) Alright, submitted bug 224199
(In reply to Greg V from comment #30) The u2f-devd port was committed to SVN as r455847. Thanks