| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Yet another occasion where we import nixpkgs-path.nix unconditionally,
so let's actually pass a nixpkgsPath to every test function.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is in reaction to upstream commit
NixOS/nixpkgs@e34ce9d1c551fb43742aada6bb43ccb1a52e64a1.
One of the changes in GnuPG 2.1.23 is that the main binary is now called
gpg instead of gpg2. See the full release announcement here:
https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000412.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using systemctl restart or systemctl stop on any of the GnuPG
services, the sockets were closed and removed.
However we are using socket activation, so a simple restart of for
example the agent would cause the socket to be closed and removed and
afterwards the gpg-agent service is unable to pick up the socket again,
thus failing to start.
This in turn has led to GnuPG starting the agent by its own, entirely
bypassing socket activation and our shiny service module.
In order to cope with this, we need to provide LD_PRELOAD wrappers also
for remove() and close(), so that we can prevent GnuPG from closing the
systemd file descriptors.
I've also added a small subtest to ensure this won't happen again in the
future.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
| |
The shell script embedded into the expect script had "set -x" enabled.
While this doesn't really hurt it doesn't really aid in debugging
either (expect -d works much better), so let's remove it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
We're not testing this thoroughly though, but this makes sure that we
don't accidentally break module support for scdaemon.
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>
|
