Allow sequoia-chameleon-gnupg in version check

[clonejo]

Problem

I tried to use sequoia-chameleon-gnupg as a drop-in replacement for GnuPG.

python-gnupg tries to detect the gpg version before doing anything. Unfortunately, the regex for that is too restrictive:

https://github.com/vsajip/python-gnupg/blob/master/gnupg.py#L1019

VERSION_RE = re.compile(r'gpg \(GnuPG(?:/MacGPG2)?\) (\d+(\.\d+)*)'.encode('ascii'), re.I)

Example output from gpg-sq:

gpg (GnuPG-compatible Sequoia Chameleon) 2.2.40
Sequoia gpg Chameleon 0.2.0
sequoia-openpgp 1.13.0
[…]

After patching the regex, my encryption smoke test went fine.

Preferred solution

@teythoon suggested this:

Not sure where this should be fixed, at first glance gpg-sq's name is acceptable and the regex on the python-gnupg side should be relaxed. What is your opinion? Should i create an issue with the python-gnupg project?

Yeah, good question. So in the first line of the output, I'd very much mention that we are not GnuPG to reduce the risk of confusion in bug reports and such. At the same time, we are likely going to see this kind of version check or sanity check everywhere. In fact, I changed the version string we print to be more like GnuPG in the past.
I'd like the regex in python-gnupg be relaxed. In fact, if you propose a change there, please ask them to use the machine readable interface to check for the version:

$ gpg --list-config --with-colons | grep cfg:version:
cfg:version:2.2.40

Alternative solutions

The bare minimum would be to add gpg-sq to the regex.

References

Original issue on sequoia-chameleon-gnupg: https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/14

[clonejo]

I wonder if python-gnupg could even pick up on gpg-sq being in $PATH and using that (if gpg is not available).

[teythoon]

I wonder if python-gnupg could even pick up on gpg-sq being in $PATH and using that (if gpg is not available).

Let's wait with that at least until we have some evidence that python-gnupg works well with the chameleon.

[vsajip]

You can specify GPGBINARY=/path/to/gpg-sq in the environment and see if all the tests run (using the patched regex). Can you share the regex change that worked for you? Will it work with GnuPG as well as the chameleon?

[clonejo]

Thanks, good idea to run the test suite. With

$ gpg-sq --version
gpg (GnuPG-compatible Sequoia Chameleon) 2.2.40
Sequoia gpg Chameleon 0.2.0
sequoia-openpgp 1.13.0
…

i ran

GPGBINARY=gpg-sq pytest

The regex i used:

VERSION_RE = re.compile(r'gpg \(GnuPG(?:/MacGPG2|-compatible Sequoia Chameleon)?\) (\d+(\.\d+)*)'.encode('ascii'), re.I)

variant	failed	passed
gnupg	1 failed	39 passed
gpg-sq, python-gnupg unchanged	30 failed	10 passed
gpg-sq, regex extended	29 failed	11 passed

I skimmed over the failures, causes i've seen:

• gpg: Command aKeygen is not implemented. (by far the most common)
• gpg: Command aSearchKeys is not implemented.
• gpg: Command aListSigs is not implemented.
• gpg: Command aDeleteKeys is not implemented.
• Some lines in the output of --import are missing, making python-gnupg think the keys have not been imported. (test_scan_keys)

In my personal test with envelope, gpg-sq already worked great for encrypting+signing emails with keys i already have in my local gnupg keyring.

[vsajip]

Would one interpret those failures to be areas where gpg-sq is not (yet?) compatible with GnuPG?

[clonejo]

gpg-sq obviously does not provide some of the GnuPG interfaces that python-gnupg uses.

Despite that, i do see value in making it possible to use python-gnupg with gpg-sq. Though maybe it should be behind a feature flag? Or is GPGBINARY=/path/to/gpg-sq already enough of a feature flag for you, @vsajip?

[vsajip]

Well, the GPGBINARY environment variable just allows you to specify a gpg-compatible executable, which python-gnupg will treat exactly as if it were gpg. From the information you've provided I can't see what the causes of the failures are, or what changes would be needed to support gpg-sq. I wouldn't want to complicate code paths or introduce long-term maintenance burdens associated with gpg-sq support, as I can't really evaluate the Chameleon's value proposition.

[teythoon]

Would one interpret those failures to be areas where gpg-sq is not (yet?) compatible with GnuPG?

Yes, not yet. The plan is to support that, so that it will be a drop-in replacement. No need to special case anything in downstream users like python-gnupg.

Having said that, using the machine-readable interface to get the version works with both GnuPG and the chameleon, and should be preferred over parsing human-readable output.

[vsajip]

should be preferred over parsing human-readable output

Fair enough, I'll change that at some point - does gpg 1.4.x also accept those command-line arguments, do you know? I'm not likely to be near my dev environment for a couple of weeks, at least.

[teythoon]

Yes it does:

% gpg1 --list-config --with-colons version
cfg:version:1.4.23

[clach04]

@clonejo did you build gpg-sq, or are there pre built binaries available? Thanks!

[clonejo]

@clonejo did you build gpg-sq, or are there pre built binaries available? Thanks!

@clach04 On Arch there is https://archlinux.org/packages/community/x86_64/sequoia-chameleon-gnupg/, or you could build it yourself with cargo install sequoia-chameleon-gnupg .

[clonejo]

Thanks!