| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Prior to NixOS/nixpkgs@cb0adc11ffb0926adae7aa2ed22835c4f9ea971c, the
"pinentry" attribute defaulted to the GTK 2 flavour, but with the
mentioned commit, the default has changed to the ncurses one.
To make sure we have the same behaviour in our VM test as we had before
that change, I explicitly changed our default pinentry to pinentry_gtk2.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the release announcement at:
https://lists.gnupg.org/pipermail/gnupg-announce/2016q4/000398.html
Unfortunately we still need the wrapper, because we need to pick up the
PID of the socket endpoint in order to gather various information we can
pass to pinentry (which then for example can recognize that the actual
SSH client is using X or is using a particular TTY).
On the upside however, this is a step into a direction I didn't imagine
to happen anytime soon, given the following statement from Werner Koch
back then:
https://lists.gnupg.org/pipermail/gnupg-devel/2014-November/029104.html
However I don't think the way I'm picking up the PID and doing
inspection of /proc/PID is going to happen in upstream GnuPG anytime
soon. But after cleaning up and doing it as a patch I might now consider
upstreaming it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
Since NixOS/nixpkgs@97bfc2fac92d90c668ae1ec078356d0bd0a9ddb7, runCommand
uses stdenvNoCC, so we don't have a compiler available anymore.
However, there is now a runCommandCC function which does exactly what we
want.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
The systemd library has been splitted off into a different output in
NixOS/nixpkgs@78178d5854901e1b17a14bce3fe43515984b7b91.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since GnuPG version 2.1.13 (NixOS/nixpkgs@b586b00), there is support for
XDG_RUNTIME_DIR so the sockets are in /run/user/gnupg instead of
~/.gnupg.
The full announcement can be found here:
https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000390.html
Unfortunately the fix is a bit more complicated, because if GNUPGHOME is
set to a non-default location, the sockets are to be found within the
directory specified in $GNUPGHOME instead.
So we also need to check the version of GnuPG so that we can properly
split up the socket directory from the GNUPGHOME.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
| |
It doesn't make sense to pollute the system with additional environment
variables if we're using the defaults anyway, so only set it if it's not
"~/.gnupg".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
We do things such as placing gnupg into environment.systemPackages, so
calling this just "programs.gpg-agent" doesn't fit that. Especially if
we really want to have a way to specify configuration values in case I'm
getting masochistic someday ;-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
