Add LTS version of GnuPG and update libgcrypt to latest LTS version

[afh]

Description of changes

In Brief:

• Add package to install GnuPG 2.2.41 and libgcrypt 1.8.10 both listed as the official Long Term Support (LTS) versions on the GnuPG project's download page
• Add gnupg-lts and libgcrypt-tls package names
• Make gnupg-lts depend on libgcrypt-tls
• Refactor shared code between 22.nix and 23.nix into common.nix

ℹ️ Updating libgcrypt from 1.5.x to 1.8.x seemed okay to me as I did not quickly find any packages depending on it.

In Detail:

The latest change of the GnuPG package (see PR #207071) has been met with both acclaim and some uncertainty.
Folks were uncertain whether NixOS should only provide the latest version or additionally offer an LTS version. The GnuPG 2.2.27 package was was replaced by the GnuPG 2.3.3 package (see 1ee8f77).

A quick investigation shows that several distributions chose the GnuPG LTS version as the default (see my comment on #207071).

@mweinelt's comment mentioning "some interoperability concerns voiced on the distributions@ list, where gnugp with 2.4.0 is incompatible with openpgp implementations following the proposed(?) IETF standard [see draft-ietf-openpgp-crypto-refresh]" inspired me to try and (re-)introduce an LTS version of GnuPG and libgcrypt, the result of which is this PR.

✅ 👋 Call for help:

Folks familiar with both or either of the packages, please chime in with additional context that may have been lost and whether the patches that are commented out can be removed or need to be updated.

Until the above call for help has been resolved I believe this PR should continue to be a draft.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[peti]

I am for it. I would use the latest version by default, but offer the LTS version for those who want it, just like this PR does. 👍

[afh]

Thanks for your comment, @peti. Delighted to hear you are for it 🙂

Would you happen to have any additional context you could share on the state of the patches as mentioned in the 👋 Call for help above by any chance?

[peti]

Would you happen to have any additional context you could share on the state of the patches as mentioned in the **👋 Call for help** [above](#215109 (comment)) by any chance?

No, I'm afraid not.

[doronbehar]

The common.nix file was not pushed.

[afh]

Thanks for bringing this to my attention, @doronbehar. It seems I'm suffering from a severe case of Monday-morning 🧠 today 😅.

[afh]

Friendly ping to @lsix, @vrthra, @fpletz about whether you may have more context about the commented tests and whether they can be removed or need to be updated.

[afh]

@trofi and @winterqt you've been so very helpful in moving forward with other PRs (#194099, #215699), mind lending a hand here to get the right people involved to get 👀 on this PR?

The main question to resolve is what should happen with the patches that do not apply (cleanly)? Once that is resolved I feel the PR is ready for review.

[trofi]

@trofi and @winterqt you've been so very helpful in moving forward with other PRs (#194099, #215699), mind lending a hand here to get the right people involved to get eyes on this PR?

The main question to resolve is what should happen with the patches that do not apply (cleanly)? Once that is resolved I feel the PR is ready for review.

I am not familiar with gnupg, thus I can only provide general review guidance that might not be in line with maintaners' preferences:

1. Avoid using common.nix and just inline the contents into all versions you provide.
2. Check if patches that failed to apply are already upstreamed. Some of them look like backports. But you are introducing older versions. Who nows what we need to backport compared to latest one.
3. Avoid the suffixes like libgcrypt-lts. Using versioned ones like libgcrypt_1_8 where needed should be enough.

Generally if there are no known problems with latest version and there are no packages that rely on outdated versions I would suggest not to provide outdated versions. Especially for security packages. Upstream should know better when to release.

[afh]

Thanks for your helpful comments, @trofi, and apologies for taking so long to reply.
I've incorporated your comments into this PR and will look into whether the patches that do not apply have already been merged upstream…

[trofi]

error: undefined variable 'pcsclite'

Can you have a look at ofborg-eval presubmit step on why it fails?

[afh]

Finally got around to inspect the patches, @trofi.

Obsoleted patches have been removed, other patches have been updated to apply cleanly.

I'm happy to remove the 0001-dirmngr-Only-use-SKS-pool-CA-for-SKS-pool.patch altogether, if folks prefer to not have it lie around unused.
The thing with this patch is that the code it patches is commented out upstream with the note that it has been "[d]isabled […] to due problems with the standard hkps pool."

[doronbehar]

I'm happy to remove the 0001-dirmngr-Only-use-SKS-pool-CA-for-SKS-pool.patch altogether

That sounds great! Could this removal be applied for the non LTS Gnupg?

[afh]

Yes, it can, @doronbehar, and I pushed an appropriate change for the removal.

For reference here are links to the upstream source showing the comment and commented code:

• GnuPG 2.4
• GnuPG 2.2

[afh]

Thought I had marked this PR as ready for review already. Apologies for the delay.
Friendly ping to @peti, @doronbehar, @trofi in case there isn't a notification about this PR draft now being a proper PR 🙂

[doronbehar]

Maybe we should rename the files in both gnupg/ and in libgcrypt/ as default.nix and lts.nix?

Besides that, looks good to me and I approve and encourage the changes, especially the cleanup commits (libgcrypt update & patch cleanup).

[afh]

Thanks for the review, @doronbehar. Glad to hear you approve and encourage the suggested changes. 🙂

@trofi suggested to "[a]void the suffixes like libgcrypt-lts. Using versioned ones like libgcrypt_1_8 where needed should be enough." Trofi's comment was about directed at package names; not sure how much of a difference that makes regarding the package filenames.

[doronbehar]

I think this is a matter of taste and the maintainers (who unfortunately don't share their voice here) should decide on those details.

[peti]

I think this is a matter of taste and the maintainers (who unfortunately don't share their voice here) should decide on those details.

I don't feel strongly about the filenames. Using the packages version number in the filename seems to be common practice, but the current scheme works fine, too. No big deal. I'm fine with the PR as it is.

[afh]

Thanks for chiming in @peti.

Kindly requesting @fpletz and @vrthra to share their voice on the proposed changes and opinion regarding nix filename and package naming 🙂

[afh]

@doronbehar, @trofi, @peti the maintainers have been unresponsive here, do any of you have merge rights to possibly get this in for the 23.05 release?

[trofi]

Oh, isn't 5000+ rebuilds a bit too much for master?

[K900]

32000 rebuilds, no less. Backing out.

[SuperSandro2000]

with lib should not be over the entire file

[doronbehar]

with lib should not be over the entire file

I think it's a left over from the copy pasted nix files, but indeed they all shouldn't use with lib; like this.

[afh]

Thanks everyone for chiming in. I'll work on the requested changes and will issue a new PR with staging as its merge base. Stay tuned!

Update: See #226006