Closed offbyone closed 1 year ago
unfortunately I do not have free time to work on this :( the code is here, I accept PRs/help from people :)
I totally get that. I wish I had the foggiest idea of how to work on macos software. Maybe it's my cue to learn :)
Workaround! Add yubiswitch as an Accessibility app:
Credit: https://github.com/pqrs-org/Karabiner-Elements/issues/1867#issuecomment-498556572
@mullender great! though when I do this, I still get an error about the helper:
“com.pallotron.yubiswitch.helper” can’t be opened because Apple cannot check it for malicious software.
nvm—just had to allow this helper in the Security & Privacy General window.
@kyleniemeyer do you have a screenshot of that? We can update the readme with a Catalina section.
Looks like this is an issue on 10.15.1 as well. The workaround doesn't work either.
@pryorda this is still working for me on 10.15.1, with the workaround
With a reboot it started working again! "Have you tried turning it off and on again?"
Neither reboot nor other sorceries made the trick for me, "solution" was quite simple, disable Automatically switch off YubiKey, kind of defeats the purpose but I can do with the shortcut while the issue is nailed.
I was able to open Yubiswitch on macos 10.15.1, by allowing the helper in the security & privacy under genral tab. At the moment it seems that yubikey remains always on no matter if yubiswitch status is on/off. I am still getting OTPs all over the place
Confirmed fixed by adding it to Accessibility and adding the right ProductID to Preferences
Confirming it works by adding to Accessibility, quit and reopen YubiSwitch, and removing and putting the YubiKey back.
For me on Catalina, it still doesn't work, even after adding yubiswitch to Accessibility and rebooting. The yubikey is always enabled.
For me it also stopped working after the update. Was able to fix it with:
It's working now! "Have you tried turning it off and on again?" all the things!
Am on Catalina 10.15.2 (19C57)
Those who hate to reboot mac after making above changes use below command to work on yubiswitch after reinsterting key.
$ osascript -e 'tell application "yubiswitch" to KeyOn'
$ osascript -e 'tell application "yubiswitch" to KeyOff'
Confirmed fixed by adding it to Accessibility and adding the right ProductID to Preferences
This was the only thing that worked for me.
ioreg -p IOUSB -l -w 0 -x | grep Yubi -A10 | grep Product
"idProduct" = 0x403
- Added Yubiswitch.app to System Preferences -> Security & Privacy -> Privacy tab -> Accessibility
Same except ... -> "Input Monitoring".
Accessibility didn't work for me.
- Added Yubiswitch.app to System Preferences -> Security & Privacy -> Privacy tab -> Accessibility
Same except ... -> "Input Monitoring".
Accessibility didn't work for me.
It's the strangest thing. My solution works hit and miss. So I tried adding it to Input Monitoring but had the same hit and miss response from the app. Sad times.
Fundamental question : Does this app help with other applets in Yubikey 5 like PIV ? for smart card operation ? or this app is specifically for only OTP applet please ? developed only to protect yubikeys from accidentally delivering OTPs?
Neither reboot nor other sorceries made the trick for me, "solution" was quite simple, disable Automatically switch off YubiKey, kind of defeats the purpose but I can do with the shortcut while the issue is nailed.
Thank you! This was also the only thing that worked for me! My friends will appreciate not getting random numeric texts from me.
I did the following in Catalina and it worked for me:
ioreg -p IOUSB -l -w 0 -x | grep Yubi -A10 | grep Product
Works great now even with "Automatically switch off yubikey. This is just a mix of what other people did but I'm leaving this for completeness (and Github karma—of course).
I did the following in Catalina and it worked for me:
* Added Yubiswitch.app to System Preferences -> Security & Privacy -> Privacy tab -> Accessibility * Added Yubiswitch.app to System Preferences -> Security & Privacy -> Privacy tab -> Input Monitoring * Set YubiKey ProductID in YubiKey Preferences (click tray icon). * Get ProductID from Terminal with: `ioreg -p IOUSB -l -w 0 -x | grep Yubi -A10 | grep Product` * This showed me 2 ProductIDs, for me it was the first one (0x407)
Works great now even with "Automatically switch off yubikey. This is just a mix of what other people did but I'm leaving this for completeness (and Github karma—of course).
Tried this over the past couple of days, still no workie.
It leaves the Yubikey enabled despite "Enable Yubikey" not being selected.
I have been experiencing this issue recently, and it seems to be due to the yubiswitch helper daemon crashing. When I kill and restart yubiswitch it restarts the helper daemon and everything is working again. The crashes are somehow related to this Mac OS "RunLoop" stuff that I am entirely ignorant about.
I'd be curious if everyone experiencing issues despite following all of the above advice is having the same problem.
You can look in Console.app's "Crash Reports" view to see if the com.pallotron.yubiswitch.helper
has crashed when you experience issues.
I have multiple crash reports like this:
Crashed Thread: 1 Dispatch queue: com.apple.root.default-qos.overcommit
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: LIBSYSTEM, [0x2]
Application Specific Information:
assertion failure: Schedule failed queue: %p runLoop: %p
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff722b9dfa mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff722ba170 mach_msg + 60
2 com.apple.CoreFoundation 0x00007fff3817df85 __CFRunLoopServiceMachPort + 247
3 com.apple.CoreFoundation 0x00007fff3817ca52 __CFRunLoopRun + 1319
4 com.apple.CoreFoundation 0x00007fff3817bece CFRunLoopRunSpecific + 462
5 com.apple.CoreFoundation 0x00007fff38204519 CFRunLoopRun + 40
6 com.pallotron.yubiswitch.helper 0x00000001035c848d main + 147
7 libdyld.dylib 0x00007fff72178cc9 start + 1
Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos.overcommit
0 libsystem_kernel.dylib 0x00007fff722d9ad6 __abort_with_payload + 10
1 libsystem_kernel.dylib 0x00007fff722db3df abort_with_payload_wrapper_internal + 80
2 libsystem_kernel.dylib 0x00007fff722db411 abort_with_payload + 9
3 libsystem_c.dylib 0x00007fff7224680b _os_crash_fmt.cold.1 + 55
4 libsystem_c.dylib 0x00007fff721d9e62 _os_crash_fmt + 154
5 com.apple.framework.IOKit 0x00007fff3af2972d IOHIDManagerScheduleWithRunLoop + 302
6 com.pallotron.yubiswitch.helper 0x00000001035c862f ____XPC_Connection_Handler_block_invoke + 323
7 libxpc.dylib 0x00007fff723bd2bc _xpc_connection_call_event_handler + 56
8 libxpc.dylib 0x00007fff723bc1cb _xpc_connection_mach_event + 934
9 libdispatch.dylib 0x00007fff7211f6f8 _dispatch_client_callout4 + 9
10 libdispatch.dylib 0x00007fff72134bc9 _dispatch_mach_msg_invoke + 435
11 libdispatch.dylib 0x00007fff72124af6 _dispatch_lane_serial_drain + 263
12 libdispatch.dylib 0x00007fff7213571c _dispatch_mach_invoke + 481
13 libdispatch.dylib 0x00007fff7212ec09 _dispatch_workloop_worker_thread + 596
14 libsystem_pthread.dylib 0x00007fff72379a3d _pthread_wqthread + 290
15 libsystem_pthread.dylib 0x00007fff72378b77 start_wqthread + 15
Thread 1 crashed with X86 Thread State (64-bit):
rax: 0x0000000002000209 rbx: 0x0000000000000000 rcx: 0x0000700000be55e8 rdx: 0x0000700000be56a0
rdi: 0x0000000000000012 rsi: 0x0000000000000002 rbp: 0x0000700000be5630 rsp: 0x0000700000be55e8
r8: 0x00007fe9d9005c70 r9: 0x0000000000000000 r10: 0x000000000000005e r11: 0x0000000000000246
r12: 0x000000000000005e r13: 0x0000700000be56a0 r14: 0x0000000000000002 r15: 0x0000000000000012
rip: 0x00007fff722d9ad6 rfl: 0x0000000000000246 cr2: 0x0000700000be3f70
Logical CPU: 0
Error Code: 0x02000209
Trap Number: 133
I'm hoping to create for myself some sort of autolaunch script that will restart the helper if it dies. Maybe with launchd.
I have been experiencing this issue recently, and it seems to be due to the yubiswitch helper daemon crashing. When I kill and restart yubiswitch it restarts the helper daemon and everything is working again. The crashes are somehow related to this Mac OS "RunLoop" stuff that I am entirely ignorant about.
I'd be curious if everyone experiencing issues despite following all of the above advice is having the same problem. You can look in Console.app's "Crash Reports" view to see if the
com.pallotron.yubiswitch.helper
has crashed when you experience issues.I have multiple crash reports like this:
Crashed Thread: 1 Dispatch queue: com.apple.root.default-qos.overcommit Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: LIBSYSTEM, [0x2] Application Specific Information: assertion failure: Schedule failed queue: %p runLoop: %p Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff722b9dfa mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff722ba170 mach_msg + 60 2 com.apple.CoreFoundation 0x00007fff3817df85 __CFRunLoopServiceMachPort + 247 3 com.apple.CoreFoundation 0x00007fff3817ca52 __CFRunLoopRun + 1319 4 com.apple.CoreFoundation 0x00007fff3817bece CFRunLoopRunSpecific + 462 5 com.apple.CoreFoundation 0x00007fff38204519 CFRunLoopRun + 40 6 com.pallotron.yubiswitch.helper 0x00000001035c848d main + 147 7 libdyld.dylib 0x00007fff72178cc9 start + 1 Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos.overcommit 0 libsystem_kernel.dylib 0x00007fff722d9ad6 __abort_with_payload + 10 1 libsystem_kernel.dylib 0x00007fff722db3df abort_with_payload_wrapper_internal + 80 2 libsystem_kernel.dylib 0x00007fff722db411 abort_with_payload + 9 3 libsystem_c.dylib 0x00007fff7224680b _os_crash_fmt.cold.1 + 55 4 libsystem_c.dylib 0x00007fff721d9e62 _os_crash_fmt + 154 5 com.apple.framework.IOKit 0x00007fff3af2972d IOHIDManagerScheduleWithRunLoop + 302 6 com.pallotron.yubiswitch.helper 0x00000001035c862f ____XPC_Connection_Handler_block_invoke + 323 7 libxpc.dylib 0x00007fff723bd2bc _xpc_connection_call_event_handler + 56 8 libxpc.dylib 0x00007fff723bc1cb _xpc_connection_mach_event + 934 9 libdispatch.dylib 0x00007fff7211f6f8 _dispatch_client_callout4 + 9 10 libdispatch.dylib 0x00007fff72134bc9 _dispatch_mach_msg_invoke + 435 11 libdispatch.dylib 0x00007fff72124af6 _dispatch_lane_serial_drain + 263 12 libdispatch.dylib 0x00007fff7213571c _dispatch_mach_invoke + 481 13 libdispatch.dylib 0x00007fff7212ec09 _dispatch_workloop_worker_thread + 596 14 libsystem_pthread.dylib 0x00007fff72379a3d _pthread_wqthread + 290 15 libsystem_pthread.dylib 0x00007fff72378b77 start_wqthread + 15 Thread 1 crashed with X86 Thread State (64-bit): rax: 0x0000000002000209 rbx: 0x0000000000000000 rcx: 0x0000700000be55e8 rdx: 0x0000700000be56a0 rdi: 0x0000000000000012 rsi: 0x0000000000000002 rbp: 0x0000700000be5630 rsp: 0x0000700000be55e8 r8: 0x00007fe9d9005c70 r9: 0x0000000000000000 r10: 0x000000000000005e r11: 0x0000000000000246 r12: 0x000000000000005e r13: 0x0000700000be56a0 r14: 0x0000000000000002 r15: 0x0000000000000012 rip: 0x00007fff722d9ad6 rfl: 0x0000000000000246 cr2: 0x0000700000be3f70 Logical CPU: 0 Error Code: 0x02000209 Trap Number: 133
I'm hoping to create for myself some sort of autolaunch script that will restart the helper if it dies. Maybe with launchd.
I personally have never had it crash.
@boogybren : to be clear, I am only referring to the yubiswitch helper -- the yubiswitch UI widget in the task bar continues to run for me while the helper is repeatedly dying.
Process commands from ps aux | grep yubiswitch
:
# helper process
/Library/PrivilegedHelperTools/com.pallotron.yubiswitch.helper
# ui widget
/Applications/yubiswitch.app/Contents/MacOS/yubiswitch
@boogybren : to be clear, I am only referring to the yubiswitch helper -- the yubiswitch UI widget in the task bar continues to run for me while the helper is repeatedly dying.
Process commands from
ps aux | grep yubiswitch
:# helper process /Library/PrivilegedHelperTools/com.pallotron.yubiswitch.helper # ui widget /Applications/yubiswitch.app/Contents/MacOS/yubiswitch
Yep, me too 👍🏼. I’ve never had the helper or the app crash on me.
Just to add on here, was able to get yubiswitch working on Catalina 10.15.6 by adding it as an Accessibility app and restarting computer. Thanks to this thread 👍
@boogybren : Thank you for the solution. Working fine after adding the Product ID to Yubiswitch's preferences (mine was 0x407).
Confirmed fixed by adding it to Accessibility and adding the right ProductID to Preferences
This was the only thing that worked for me.
- Added Yubiswitch.app to System Preferences -> Security & Privacy -> Privacy tab -> Accessibility
- Grabbed ProductID
ioreg -p IOUSB -l -w 0 -x | grep Yubi -A10 | grep Product
"idProduct" = 0x403
- Plugged ProductID into Yubiswitch preferences
- Enabled YubiKey (had to do this twice before I could disable)
- Disabled YubiKey
I'm running into similar problems. Tried pretty much everything suggested in this thread, no luck. :/
ioreg -p IOUSB -l -w 0 -x | grep -i Yubikey -A10 | grep 'idProduct\|idVendor'
| | "idProduct" = 0x407
| | "idVendor" = 0x1050
| "idProduct" = 0xa131
(it's the first one for me, 0x407
, verified via System Information
)
helper
app
Process: com.pallotron.yubiswitch.helper [7829]
Path: /Library/PrivilegedHelperTools/com.pallotron.yubiswitch.helper
Identifier: com.pallotron.yubiswitch.helper
Version: 1.0
Code Type: X86-64 (Native)
Parent Process: launchd [1]
Responsible: yubiswitch [7822]
User ID: 0
Date/Time: 2020-11-15 07:40:15.118 -0500 OS Version: Mac OS X 10.15.7 (19H15) Report Version: 12 Anonymous UUID: 1BC070E9-0122-9916-9DB1-B2EA1C4A520B
Time Awake Since Boot: 1100 seconds
System Integrity Protection: enabled
Crashed Thread: 1 Dispatch queue: com.apple.root.default-qos.overcommit
Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: LIBSYSTEM, [0x2]
Application Specific Information: assertion failure: Schedule failed queue: %p runLoop: %p
Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff738d6dfa mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff738d7170 mach_msg + 60 2 com.apple.CoreFoundation 0x00007fff39725ef5 CFRunLoopServiceMachPort + 247 3 com.apple.CoreFoundation 0x00007fff397249c2 CFRunLoopRun + 1319 4 com.apple.CoreFoundation 0x00007fff39723e3e CFRunLoopRunSpecific + 462 5 com.apple.CoreFoundation 0x00007fff397ac489 CFRunLoopRun + 40 6 com.pallotron.yubiswitch.helper 0x000000010ce0548d main + 147 7 libdyld.dylib 0x00007fff73795cc9 start + 1
Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos.overcommit 0 libsystem_kernel.dylib 0x00007fff738f6ad6 abort_with_payload + 10 1 libsystem_kernel.dylib 0x00007fff738f83df abort_with_payload_wrapper_internal + 80 2 libsystem_kernel.dylib 0x00007fff738f8411 abort_with_payload + 9 3 libsystem_c.dylib 0x00007fff7386380b _os_crash_fmt.cold.1 + 55 4 libsystem_c.dylib 0x00007fff737f6e62 _os_crash_fmt + 154 5 com.apple.framework.IOKit 0x00007fff3c4d472d IOHIDManagerScheduleWithRunLoop + 302 6 com.pallotron.yubiswitch.helper 0x000000010ce0562f __XPC_Connection_Handler_block_invoke + 323 7 libxpc.dylib 0x00007fff739da22c _xpc_connection_call_event_handler + 56 8 libxpc.dylib 0x00007fff739d913b _xpc_connection_mach_event + 934 9 libdispatch.dylib 0x00007fff7373c6f8 _dispatch_client_callout4 + 9 10 libdispatch.dylib 0x00007fff73751bc9 _dispatch_mach_msg_invoke + 435 11 libdispatch.dylib 0x00007fff73741af6 _dispatch_lane_serial_drain + 263 12 libdispatch.dylib 0x00007fff7375271c _dispatch_mach_invoke + 481 13 libdispatch.dylib 0x00007fff7374bc09 _dispatch_workloop_worker_thread + 596 14 libsystem_pthread.dylib 0x00007fff73996a3d _pthread_wqthread + 290 15 libsystem_pthread.dylib 0x00007fff73995b77 start_wqthread + 15
Thread 1 crashed with X86 Thread State (64-bit): rax: 0x0000000002000209 rbx: 0x0000000000000000 rcx: 0x000070000a0085e8 rdx: 0x000070000a0086a0 rdi: 0x0000000000000012 rsi: 0x0000000000000002 rbp: 0x000070000a008630 rsp: 0x000070000a0085e8 r8: 0x00007fb5bed06b40 r9: 0x0000000000000000 r10: 0x000000000000005e r11: 0x0000000000000246 r12: 0x000000000000005e r13: 0x000070000a0086a0 r14: 0x0000000000000002 r15: 0x0000000000000012 rip: 0x00007fff738f6ad6 rfl: 0x0000000000000246 cr2: 0x000000010ce89000
Logical CPU: 0 Error Code: 0x02000209 Trap Number: 133
I even looked up the error message, found [this SO post](https://stackoverflow.com/a/36442699/120818), tried to make a modification to the helper myself (diff below), but I have no idea what I'm doing with XCode and Mac apps, so I think I screwed it up, I'm still getting the same errors.
@@ -169,8 +169,9 @@ void signalHandler(int signum) { int main(int argc, const char *argv[]) { signal(SIGINT, signalHandler); signal(SIGTERM, signalHandler);
I dunno what else to try. So sad. :(
I finally found what the issue was (for me, at least) - I was running Karabiner-Elements and while that is active, it competes with YubiSwitch for keyboard control somehow (no idea where the conflict is, I just know that it exists). So as soon as I quit Karabiner-Elements, YubiSwitch starts working for me - yay! ;]
System Information lists 0x0407 which I had used and was disappointed it wasn't working anymore, the ioreg
version being discussed above prints 0x407. Configuring 0x407 as the ProductID allows yubiswitch to work appropriately.
System Information lists 0x0407 which I had used and was disappointed it wasn't working anymore, the
ioreg
version being discussed above prints 0x407. Configuring 0x407 as the ProductID allows yubiswitch to work appropriately.
Just tried this and it still doesn't work for me. :-/
System Information lists 0x0407 which I had used and was disappointed it wasn't working anymore, the
ioreg
version being discussed above prints 0x407. Configuring 0x407 as the ProductID allows yubiswitch to work appropriately.
KUDOS!! This fixed it for me! Thank you.
@boogybren Did you use 0x407
? Or did you use what your ProductID is, omitting any leading zero(es) after the x?
I used the product id spit out by ioreg
which in my case was also 0x407
I'm happy to hear that. But, you're not boogybren :).
@VxJasonxV Tried it both with and without the 0
. No dice.
Ok, but that didn't answer the entirety of the question. Is your YubiKey's ProductID 0x0407? That ProductID is key type and feature level specific. And maybe generation specific too.
What is your YubiKey's ProductID?
@VxJasonxV Please see screen recording. It shows my ProductID, Yubiswitch settings and me being able to use my Yubikey with Yubiswitch enabled or disabled.
And yubiswitch also has Accessibility features allowed? From earlier in this issue; https://github.com/pallotron/yubiswitch/issues/86#issuecomment-547716814
And yubiswitch also has Accessibility features allowed? From earlier in this issue; #86 (comment)
Correct. I've been trying to get this to work since early 2020. Whenever someone comments here with success, I give it a go. All remedies thus far have not worked for me.
Adding this in case it helps other MacOS noobs: If you see the "Apple cannot check it for malicious software" message when attempting to run the yubiswitch app, you'll need to unlock the padlock and choose "Open anyway":
Disabling "Auto switch off Yubikey" does the trick for me, as in https://github.com/pallotron/yubiswitch/issues/98 .
Tested on Intel MBP 2020 (Big Sur) and M1 Pro 2021 (Monterey)
This PR is supposed to fix the helper crash: https://github.com/pallotron/yubiswitch/pull/108 But there isn't a new installable image built yet.
0.14 is out with the #108 PR.
Being a person of brave and foolish disposition, I upgraded to Catalina last night. Now, my Yubikey won't stop sneezing everywhere.
cccccckieueekfeiuliltlfthijuljttdijhrjinkfvd
Achoo!
Below is the log for the daemon captured from the moment I turn it on (This is console.app searching for the
yubiswitch
process)This is a search for
yubikey
: