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>
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.
Presently, gnupg1compat only works with gnupg22. Without this change, the error
```
error: attribute 'version' missing, at .../nixpkgs/pkgs/tools/security/gnupg/1compat.nix:4:26
```
is emitted when evaluating
```
pkgs.gnupg1compat.override { gnupg = pkgs.gnupg20; }'
```
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/gnupg/versions.
These checks were done:
- built on NixOS
- /nix/store/bxq2w522d82qykwqi8wscm4v105zs2bq-gnupg-1.4.23/bin/gpgsplit passed the binary check.
- /nix/store/bxq2w522d82qykwqi8wscm4v105zs2bq-gnupg-1.4.23/bin/gpg passed the binary check.
- /nix/store/bxq2w522d82qykwqi8wscm4v105zs2bq-gnupg-1.4.23/bin/gpgv passed the binary check.
- /nix/store/bxq2w522d82qykwqi8wscm4v105zs2bq-gnupg-1.4.23/bin/gpg-zip passed the binary check.
- 4 of 4 passed binary check by having a zero exit code.
- 1 of 4 passed binary check by having the new version present in output.
- found 1.4.23 with grep in /nix/store/bxq2w522d82qykwqi8wscm4v105zs2bq-gnupg-1.4.23
- directory tree listing: https://gist.github.com/37dc2e87340f0983866c3c125172de27
- du listing: https://gist.github.com/4a84db46e37bd6d372fe020cc7826838
"platforms.gnu" has been linux-only since at least 17.03:
$ nix eval -f channel:nixos-17.03 lib.platforms.gnu
[ "i686-linux" "x86_64-linux" "armv5tel-linux" "armv6l-linux" "armv7l-linux" "aarch64-linux" "mips64el-linux" ]
Unlike platforms.linux, platforms.gnu indicates "must use glibc"
which for the most part is not intended.
Replacing platforms.gnu with platforms.linux would be the same "today"
but let's err on preserving existing behavior and be optimistic
about platforms these packages work on.