This solves the dependency cycle in gcr alternatively so there won't be
two gnupg store paths in a standard NixOS system which has udisks2 enabled
by default.
NixOS users are expected to use the gpg-agent user service to pull in the
appropriate pinentry flavour or install it on their systemPackages and set
it in their local gnupg agent config instead.
Co-authored-by: Florian Klink <flokli@flokli.de>
See discussion at
https://github.com/NixOS/nixpkgs/pull/63952#issuecomment-507048690.
Upstream commit:
commit 1c9cc97e9d47d73763810dcb4a36b6cdf31a2254
Author: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Sun Jun 30 11:54:35 2019 -0400
dirmngr: Only use SKS pool CA for SKS pool
* dirmngr/http.c (http_session_new): when checking whether the
keyserver is the HKPS pool, check specifically against the pool name,
as ./configure might have been used to select a different default
keyserver. It makes no sense to apply Kristian's certificate
authority to anything other than the literal host
hkps.pool.sks-keyservers.net.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
GnuPG-Bug-Id: 4593
See https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f.
The SKS network is vulnerable to certificate poisoning, which can
destroy GnuPG installations. keys.openpgp.org is a new non-SKS keyserver
that is resistant to this type of attack.
With such an attack being possible, it is unsafe to use SKS keyservers
for almost anything, and so we should protect our users from a now
unsafe default. keys.openpgp.org offers some (but not all) functionality
of SKS, and is better than nothing.
This default is only present in gnupg22. gnupg20 and gnupg1orig are not
affected.
He prefers to contribute to his own nixpkgs fork triton.
Since he is still marked as maintainer in many packages
this leaves the wrong impression he still maintains those.
