Replace deprecated distutils.version.StrictVersion.

[znewman01]

distutils is deprecated as of Python 3.10. We were only using it for StrictVersion, which parses a version string and lets you order the result.

The official recommendation from the packaging team is to replace StrictVersion with a dependency on the packaging package, but:

1. The Python version parser was a little different from GPG versioning anyway because it's made for Python versions (it had support for "prerelease tags").
2. I wanted to avoid adding dependencies if possible.

This PR adds a new Version class in securesystemslib.gpg.util and uses that instead.

It's a breaking change to gpg.util.get_version(), but AFAICT that wasn't ever intended for public consumption.

Signed-off-by: Zachary Newman [email protected]

Fixes: N/A

Please verify and check that the pull request fulfils the following requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[jku]

This may be off topic for your PR but since you're touching this you may have an opinion: I wonder how much work would it be to use an actual API like https://pypi.org/project/python-gnupg/ or https://pypi.org/project/gpg/ for the ~2 gpg commands we need? Spawning new processes via a command line makes me feel dirty (and is a great source of testing trouble).

[joshuagl]

Some related discussion in #428
tl;dr – we don't want to run gpg commands, but we don't want to add dependencies either. Discussion in #428 strives to find a middle ground.

[znewman01]

Spawning new processes via a command line makes me feel dirty (and is a great source of testing trouble).

I'm generally sympathetic to that point of view. While I do think minimizing dependencies is nice, to my mind, there's not much difference between "depends on GPG" and "depends on GPG+Python bindings to GPG."

That said, my most immediate goal is to fix #428 and reduce flakiness in CI for go-tuf; I think the very minor change in #429 would fix it but we need to couple that with some extra testing (#434).

[jku]

Seems reasonable to me, especially if we consider the whole "library spawns other binaries and parses output" as a hack that securesystemslib should probably get rid of.

Left a comment but even that does not seem critical (I don't think it'll break anything in this decade)

[jku]

These are both valid for StrictVersion.

Obviously we don't need to re-implement StrictVersion here (we know this is a hack, it just has to work well enough for this specific case) but at least the latter one seems strange to me -- is this just because gpg historically hasn't used multidigit minor versions?

[lukpueh]

Good question. Unfortunately, I can't remember if it was just an assumption based on the existing version progression (e.g. last 1.x was 1.9), or if there was a stronger indication somewhere. Happy to change, although not necessarily in this PR, which just uses the regex that was already there.

[jku]

oh you're right: no new bugs then :)

[lukpueh]

I wonder how much work would it be to use an actual API like https://pypi.org/project/python-gnupg/ or https://pypi.org/project/gpg/

Too much work for the benefit. See #247 and https://wiki.python.org/moin/GnuPrivacyGuard

Tl;DR: Both packages you suggest also just spawn a process to run the gpg command, the former via subprocess, the latter via GPGME C binding. So far we haven't found a good alternatives to our "hack".

[lukpueh]

Great work. Looks more robust, than it was before. Regarding backwards-compatibility, I confirm that gpg.util.get_version() was not intended as public API.