-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
yubikey-agent: init at 0.1.3 #92936
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
yubikey-agent: init at 0.1.3 #92936
Conversation
3a4131e
to
7092274
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the code! I don't think we should reinvent yet another pinentry selection, so we should just reuse the one from the gnupg module for the time being.
Is there any context/docs on why I did some digging in #90214 (comment), so would be nice to hear @FiloSottile's opinion on that as well :-) |
@flokli thank you for your thorough review! I agree with most of your points and will update the PR. Yes, the way The gnupg nix package sets a hardcoded absolute path to pinentry. This works ok because programs like yubikey-agent pulls pinentry from PATH, and it does so in a 3rd party module (it's actually within I'm not sure I can think of a better alternative. |
Doing the dance via the socket-activated gpg-agent.service in each users' systemd session was mostly done to avoid shipping the whole runtime closure of all (also graphical) pinentry flavours, and to provide a way to select the flavour (#71095), but as written in #90214 (comment), discovering from We might want to open a discussion with the GnuPG people about why pinentry discovery there is the way it is, and why it's not defaulting to looking for it in I'd like to understand the reasoning on why it currently doesn't do that (and if |
Let’s assume we go with your proposal to just look for pinentry in PATH (for both gnupg and yubikey-agent). What happens if there is no |
|
128ff96
to
d883cfa
Compare
Okay, I've pushed a couple of updates. Key unresolved issues:
To expand on the pinentry discussion: as a starting point, I feel that a nix closure should contain everything it needs to function correctly. This is why, in general, nix packages depend on other packages via absolute store paths and not via PATH. If you have a dependency via PATH, that does not form part of the closure, and when you copy the closure to another system, you won't copy the dependency. However, I can see how pinentry is a bit of a weird edge case: users might reasonably want to configure different types of pinentry, and they shouldn't have to install all the pinentries in order to use just one of them. It's also worth noting that the dynamics on macOS are different: on macOS, there is only one pinentry implementation, and I think gnupg and yubikey-agent should just use it without any extra configuration. But on Linux (and probably other unixes) it's useful to be able to dynamically choose a pinentry program. I must confess I read some of the discussions that @flokli linked to above (such as #90214 (comment)) but it's really hard to get context by jumping partway through a conversation and chasing back through many linked issues so it's mostly going above my head. But my understanding is: 1) gnupg has a baked-in pinentry choice, 2) gnupg allows users to choose a different pinentry at invocation time, 3) there is some desire (I don't know why) that gnupg should be able to use pinentry from PATH. In any case, the design of gnupg sounds like a live issue, so we shouldn't assume the current gnupg packaging is the correct way to go. Right now my feeling is:
How does that sound? |
@FiloSottile Thanks for the offer! I think we need to discuss things a bit further here but we may well take you up on this. |
d883cfa
to
70fcbc1
Compare
Added @rawkode as a maintainer, ref: #92965 (comment) |
70fcbc1
to
ab5373b
Compare
I pushed another update. I've pulled in the systemd unit from FiloSottile/yubikey-agent#43 but the relative path trick gave me the error: I have removed baking in pinentry to PATH, except on macOS where we bake in pinentry_mac since there's no other choice. I still haven't come up with a solution to reusing the gpg-agent pinentry selection (see #92936 (comment)). |
Yeah, this is expected. On NixOS, we set this to
Is there not a native pinentry provided in
Yeah, this is still somewhat pending. I'd probably prefer moving pinentry selection into a module both used from the gnupg module and this module over duplicating it… |
macOS doesn’t provide one, no. The user might have installed one via gpgtools or homebrew, but plain macOS doesn’t have a pinentry. |
ab5373b
to
e340c13
Compare
@flokli I've just pushed an update. It turns out the magic word I needed was I think this resolves all the issues we had. PTAL 😄 |
I'm learning a lot from monitoring this, thank you for your persistence @philandstuff |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the persistence too :-) I think the pinentry problem could be solved without the mkMerge
, sent another review.
This adds yubikey-agent as a package and a nixos module. On macOS, we use `wrapProgram` to set pinentry_mac as default in PATH; on Linux we rely on the user to set their preferred pinentry in PATH. In particular, we use a systemd override to prefix PATH to select a chosen pinentry program if specified. On Linux, we need libnotify to provide the notify-send utility for desktop notifications (such as "Waiting for Yubikey touch..."). This might work on other flavors of unix, but I haven't tested. We reuse the programs.gnupg.agent.pinentryFlavor option for yubikey-agent, but in doing so I hit a problem: pinentryFlavour's default value is specified in a mkDefault, but only conditionally. We ought to be able to pick up the pinentryFlavour whether or not gpg-agent is running. As a result, this commit moves the default value to the definition of programs.gnupg.agent.enable.
e340c13
to
e4029c3
Compare
@flokli pushed another update |
This LGTM. I poked upstream for a new release containing the unit file in FiloSottile/yubikey-agent#43 (comment), so we could avoid duplicating this. cc @Ma27 on the pinentry changes. |
Okay, let's merge this as-is. We can always move to the upstream-provided systemd unit, once there's a new release. 👍 Thanks for your work! |
Mea culpa: in NixOS#92936, I did originally test on macOS but I forgot to retest after adding the piv-go patch. Unfortunately, the piv-go patch is broken on macOS (but fortunately it is unnecessary).
Mea culpa: in NixOS#92936, I did originally test on macOS but I forgot to retest after adding the piv-go patch. Unfortunately, the piv-go patch was broken on macOS. This pulls in the latest version of go-piv/piv-go#75 which works on macOS now.
Another problematic platform is i686. I expect it would be OK not to build on unusual platforms unless it made default NixOS depend on the package. I checked it's not fixed by #93850. You can test on x86_64 by building |
The PR was merged, so we can try to fix i686 at a later time. I opened go-piv/piv-go#76 for investigation. |
Motivation for this change
This adds yubikey-agent as a package and a nixos module.
The yubikey-agent is impure in how it calls pinentry; I tried patching
gopass to point at a particular
pinentry
but this changes the value ofvendorSha256
depending on the particular choice of pinentry program,which felt frustratingly difficult. Instead, we use
wrapProgram
toset a default pinentry in PATH, and use a systemd override to prefix
PATH to select a chosen pinentry program if specified.
On linux, we need libnotify to provide the notify-send utility for
desktop notifications (such as "Waiting for Yubikey touch...").
The systemd unit a copy of the one in the upstream repo, in systemd.md:
https://github.com/FiloSottile/yubikey-agent/blob/master/systemd.md
This might work on other flavors of unix, but I haven't tested.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)