Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: ../util/libutil.a(estream-printf.o):/build/gnupg-1.4.23/util/../include/memory.h💯 multiple definition of
`memory_debug_mode'; gpgsplit.o:/build/gnupg-1.4.23/tools/../include/memory.h💯 first defined here
Emacs + nix-mode highlights this file just fine without this comment
for me, so I assume the problem in nix-mode has been fixed in the five
years since this comment was added.
This adds a patch series which allows GnuPG to import updates
(revocations and subkeys) from certificates that contain no user ids.
This is relevant for refreshing keys from the default keyserver
keys.openpgp.org, where only user ids that contain verified email
addresses will be distributed, and revoked keys never contain any user
ids.
This patch series was originally authored and submitted to upstream half
a year ago (by me), but now comes from Debian packaging where it's been
included since then.
Relates to the following upstream issue: https://dev.gnupg.org/T4393
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>
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.
Sergei Trofimovich