Conflicting versions of the gnupg packages

[Moises Henriquez]

The current state of the git tree has a gnupg package at version 2.0.x and a gnupg2 at version 2.1.x.. This is wrong in 2 ways.

They both provide 2 versions of the same things. The gnupg package should have been reverted to version 1.x if it is to be kept on the repositories. The gnupg2 package is missing a symlink from gpg2 to gpg in /usr/bin.

Seems that the STD ISO is using gnupg2, so I have re-built the gnupg2 package to provide the missing symlink and added a conflict definition to the gnupg package.

See https://www.gnupg.org/download/

At this moment, no package in 7.2 is requiring gnupg version 1.x, so this is a minor issue.

PROPOSAL: Downgrade the gnupg package to version 1.x, and add a conflict definition in it to list gnupg2.

[Black Clover]

I ran this test:

Created keys with Knoppix and gnupg-1.4.12 RSA - 1024

Encrypted a file armored

Exported the keys to a USB

Imported the keys to VL-Light-Final with gpg-2.1.23 and gpg-0.9.10

Decrypted the file.

No problem.

[roarde]

I was looking at an older guilde for using GnuPG (1) for communicating with PGP-2 users. Seems that doing so was non-standard in the first place, and had to be specifically added to one's own GnuPG. https://www.gnupg.org/gph/en/pgp2x.pdf Also note the years mentioned for GnuPG and PGP's step-up to PGP 3, based on OpenPGP.

I don't think we need gnupg 1 at all, especially after the test Black Clover did. Probably remove gnupg and its builder, and create the suggested symlink in the gnupg2 package. For someone to have earlier files or messages not decodeable by gnupg2 is rare in the extreme; their building gnupg 1 from source would be better than continuing to propagate confusion by having 1 more handy.

[roarde]

I retract my above recommendation. It now appears to me that it's a bad idea to link gpg2 to gpg, and that we should continue to provide a gpg-1.* package. Here's why.

Does anyone know of packages or system scripts that couldn't get along without /usr/bin/gpg? When the application is called by that name, I believe a certain behavior is expected even if the encryption and decryption could be done by either gnupg or gnupg2.

It's likely that gnupg-1* and gnupg2 can both be installed without conflict. I saw a small variety of references to this, including https://superuser.com/questions/655246/are-gnupg-and-gnupg2-compatible-with-each-other and http://pkgsrc.se/security/gnupg2 .

So let's continue to provide a gpg-1.* package for now, and have gpg2 take the "gpg" name only when the upstream source makes it that way. If the "wrong" gpg is used, the answer is to export the key using the gpg that created it, then import that key into the other. So we don't want either in the other's slack-conflicts; this likely use case almost requires them to be side-by-side.

[roarde]

Still looking at this.

The remaining unanswered question is whether keyrings and encrypted files created by gnupg 2.0 are directly accessible by either gnupg-1.4 or gnupg2-2.[12]. That is, would 2.0's keyrings and keys need to be exported by 2.0 itself, first? 2.1+ is not an upgraded 2.0. They're incompatible in several ways. 1.4 came after 2.0 and perhaps has the tools to deal with 2.0 keys, but that info is hard to find.

[roarde]

EOL for the 2.0 series is the end of 2017, so whether to supply that is a moot point. Any key it used can be read by either 1.4 (most of them) or 2.2 (a few).

So I finally end up at install gnupg2 by default, and also provide gnupg-1.4 in repos, and don't symlink gpg to gpg2.

It would be nice to have another opinion before I call for building 1.4.

[roarde]

edit: Upstream sneezed again. The below is now a bad idea and should not be done, at least not as stated. See next comment.

If there is no further input, I ask that the "gnupg" package be rebuilt using the latest 1.x. Once that's done, I'll close the issue.

[roarde]

At version 2.1.23, the GnuPG project changed the name of the binary from "gpg2" to "gpg". That change has carried over into the 2.2 series, which has been announced as LTS and a replacement for the 2.0 series.

Investigation is needed as to whether the gnupg-2.2 will handle all the data encrypted by 2.0 that our users may still have. If it does, then it's obvious that the "gnupg" (2.0.x) package should be removed, and the conflict retained in gnupg2; but with the symlinking reversed.

For next OS version, it may be more practical to call the package "gnupg" to match now-current practices elsewhere.

[roarde]

Upgrade gnupg-2.0 with gnupg-1.4.22

Addresses Issue #116

→ <<cset 03091c869d00>>