Closed weilbith closed 3 years ago
Hey! I wish it was possible, that would have been just awesome... For gpg
this code is not even using any official or supported API, just a bunch of hacks that happen to somehow work more or less reliably - but even if we did, I think we intercept these signals on such a low level that all we really know is that gpg
is somehow involved, but not who or what triggered it.
What I usually do (by hand, not automated), is if I see a touch request that I don't recognize, I open htop
and search for gpg
and see the process tree... Maybe we can have some shell one-liner that can print such a tree, or its topmost level? 🤔
Hmm. Your "hack" sounds quite cumbersome for a daily workflow. Sorry. :expressionless: But eventually this is the way to go. Just in an improved manner. :thinking: I'm atm also experiencing the issue that I always get the notification, also gpg is using a different key (yeah, I still have such legacy...). Although that should get less over time, this is kinda confusing. ^^ Do you think it is possible to listen to the gpg-agent socket? :thinking:
I was told that it should be possible, and honestly it would be much preferred, if this can be made to work... But I didn't manage to find any documentation about it. If you want to give it a try, this is highly appreciated 😜 Even if this won't give us any additional information, getting the data from gpg-agent should be a lot more reliable. The problem is, I am not sure if gpg itself knows what a "yubikey touch" is, i.e. if this is part of some standard or not. Because it's not enough to know if there is gpg operation, some people configured touch on signature, others didn't, we don't want any wrong signals...
I was told that it should be possible, and honestly it would be much preferred, if this can be made to work... But I didn't manage to find any documentation about it. If you want to give it a try, this is highly appreciated stuck_out_tongue_winking_eye Even if this won't give us any additional information, getting the data from gpg-agent should be a lot more reliable.
I can give this some research. Maybe I find something. Or trial and error... :see_no_evil: But I have absolutely no clue about Go as programming language. And I must admit that I have barely time to learn a new language atm. So I eventually would just feed your with the information I figured out.
The problem is, I am not sure if gpg itself knows what a "yubikey touch" is, i.e. if this is part of some standard or not. Because it's not enough to know if there is gpg operation, some people configured touch on signature, others didn't, we don't want any wrong signals...
Hmm. Probably not. But it would be at least an improvement to check if the agent is contacting the smart card and if the vendor is Yubico.
Maaaybe there is an interface of the YubiKey itself? I mean sure there are plenty. But eventually some YubiKey specific to get such information. But there I have minimal hope. That would basically mean a full rework of your detector
package (how you call this at Go?). :stuck_out_tongue:
I chatted with folks from Yubico back when I initially created the tool, there was nothing, so I'm afraid there truly isn't anything lik YubiKey API even today 😞
:+1: for this issue, even if it would be implemented in a very hacky way. Knowing what command (e.g. via PID) accesses the key would be very helpful from security point of view. Ba, even knowing which applet waits for touch, which should be available without any new code would already be a good improvement! So you can distinguish if it's KeePassXC, YubicoAuthenticator or GPG or git (ssh) requesting it!
Hey, it's me again. I was just wondering if it would be possible to show any additional information within the notification? More about the context or rather who/what is triggering the request. Because I have some background tools which use
gpg
. If I always just touch the YubiKey without knowing for what, this could simply become a security leak. At the moment I try to send notifications myself to inform myself which application is triggering the action (after all that's isn't much safer and opens for other opportunities). Anyway, I took a glance at your implementation, but I must admit that I wasn't able to determine which eventual additional information you can actually get. But it would be amazing if there would be some. Thanks for sharing!