Since https://github.com/NixOS/nixpkgs/pull/71095, gpg doesn't have pinentry support included by default. As a result, gpg is pretty much broken in home-manager, throwing errors like
gpg: signing failed: No pinentry
gpg: default.nix: clear-sign failed: No pinentry
or
error: gpg failed to sign the data
fatal: failed to write commit object
when signing git commits.
The recommended solution is to use gpg-agent that has --pinentry-program .. given, which the NixOS module for gpg-agent does now: https://github.com/NixOS/nixpkgs/pull/71095/files#diff-46c0e5e66d829e49bf18bc90891c2c90R100
We should also do something like this for home-manager.
Yeah, I guess simply copying over the agent.pinentryFlavor option would work except the choosing of default pinentry. I suppose the most straight-forward would be to leave it without a default, forcing the user to choose 😕
Just got bit by this. Adding programs.gpg.settings.pinentry-program = "/path/to/bin/pinentry"; doesn't help, I just get gpg: invalid option.
Setting
programs.gpg-agent.extraConfig = ''
pinentry-program ${pkgs.pinentry.gnome3}/bin/pinentry-gnome3
'';
helped.
@j0xaf that did the trick (with slight changes... services not programs, package name is pinentry-gnome), thanks!
Yeah, I guess simply copying over the
agent.pinentryFlavoroption would work except the choosing of default pinentry. I suppose the most straight-forward would be to leave it without a default, forcing the user to choose confused
I think just choosing any pinentry program would be better than leaving it without a default. The current behaviour is very confusing, especially because gpg's error messages are not very helpful in finding the cause of this issue.
@timokau would you be interested in updating the gpg-provided pinentry to be a wrapper as described in https://github.com/NixOS/nixpkgs/issues/73332#issuecomment-557706889 ? This should also improve out-of-the-box experience with home-manager.
@flokli I won't do that myself any time soon, but you can CC me if you decide to do it yourself.
with slight changes...
servicesnotprograms
What's the difference?
The gnome3 pinentry seems to be broken:
No Gcr System Prompter available, falling back to curses
@benkolera suggested to use the qt one instead, which works for me:
{
services.gpg-agent = {
enable = true;
extraConfig = ''
pinentry-program ${pkgs.pinentry.qt}/bin/pinentry
'';
};
}
See #965 for related PR.
Could the gnome3 issue be related to gnome-keyring? @Infinisil Do you use gnome-keyring? I have noticed network manager having issues with getting VPN passwords through gnome keyring since updating to 19.09… 😕
Perhaps adding
services.dbus.packages = [ pkgs.gcr ];
to the system configuration helps?
Edit: I actually already seem to have pkgs.gcr in my home.packages since a long time… And both
$ gdbus introspect --session --dest org.gnome.keyring.SystemPrompter --object-path /org/gnome/keyring/Prompter
and
$ gdbus introspect --session --dest org.gnome.keyring.PrivatePrompter --object-path /org/gnome/keyring/Prompter
print available interfaces. So perhaps is sufficient to have gcr in the user configuration?
Just to add, I'm not particularly fond of this pinentryFlavor option, or rather the need to make a hard choice. I think the default should should be a wrapper package that dynamically chooses the right pinentry depending on the currently running desktop environment. It seems to me that it should only be necessary to change the option if one would like to slim down the system by reducing the "generic pinentry" closure.
Also, with the current setup I don't see how you would setup it up if you want have, for example, both KDE and Gnome desktops available on your system.
See this commit for why gnome3 pinentry is broken.
I think the default should should be a wrapper package that dynamically chooses the right pinentry depending on the currently running desktop environment. It seems to me that it should only be necessary to change the option if one would like to slim down the system by reducing the "generic pinentry" closure.
How would the script dynamically install the right pinentry? Or are you suggesting it depends on all the different flavors?
Is it expected that this breaks older nixpkgs?
@leo60228 The master branch of HM is following Nixpkgs/NixOS unstable and makes no guarantees about compatibility with released versions. You'll want to use the release-19.09 branch of HM with the 19.09 release of Nixpkgs.
hmm I'm on home-manager the home-manager 20.03 channel and I can't sign any commit with git, nor just gpg clearsign probably due to this.
All I have set relevant to this are:
programs.gpg = {
enable = true;
settings = {
default-key = "<key-fingerprint>";
};
};
programs.git = {
enable = true;
signing = {
signByDefault = true;
key = "<key-fingerprint>";
};
setting pinentry flavor also doesn't seem to help.
Is there something I should be doing?
@ZerataX Did you start the gpg agent?
My setup (that works fine enough on a recent unstable, though I should change it to use the pinentry flavour now that it is here, lol):
https://github.com/benkolera/nix/blob/master/home-manager/default.nix#L250
@benkolera As in services.gpg-agent = true;?
yeah I tried with and without that line.
Copying over that section doesn't seem to work, instead I get:
error: attribute 'default-key' missing
$ nixos-version
20.03.1822.5adf2a6c116 (Markhor)
$ nix-channel --list
home-manager https://github.com/rycee/home-manager/archive/release-20.03.tar.gz
@ZerataX Please open a new issue. Include in that issue as much information as possible about the problem you are seeing and the steps you've taken to investigate it.
@ZerataX You mean services.gpg-agent.enable = true;, right? (note the enable)
Most helpful comment
Just to add, I'm not particularly fond of this
pinentryFlavoroption, or rather the need to make a hard choice. I think the default should should be a wrapper package that dynamically chooses the right pinentry depending on the currently running desktop environment. It seems to me that it should only be necessary to change the option if one would like to slim down the system by reducing the "generic pinentry" closure.Also, with the current setup I don't see how you would setup it up if you want have, for example, both KDE and Gnome desktops available on your system.