pgpy has been using TZ-naive datetime objects, despite all OpenPGP
wire-format dates being essentially UTC.
Better to represent the datetime objects explicitly as UTC.
Closes: #401
As new versions of OpenPGP signatures are defined, implementations may
provide multiple signatures, one of an older version for legacy
clients and one of a new version for clients that can read the new
signature form.
PGPy should skip over any signature whose version is not recognized.
In commit 08a76fdda9, distutils was
dropped. Before then, gpg_ver was a global mutable class instance,
mutated inside a function and then used. After then, it's a global
string that is... also modified inside a function and then used.
Strings cannot be modified inside functions like that. It shadows the
variable in the local scope, which means the global variable is
inaccessible now. In fact the global variable exists solely to be used
inside this function, but now it cannot be.
So, because it can be bound inside the function, it *must* be, but only
if python-gpg was installed did this actually occur. If not, we skipped
the integration tests and then tried to log the version, assuming that
the global default value of "unknown" was still bound, which is no
longer true.
As per RFC 4880 13.2, "Since TripleDES is the MUST-implement algorithm,
if it is not explicitly in the list, it is tacitly at the end."
Some keys in the wild do not have it explicitly in the list, so put it
there as a default.
The OpenPGP specifications are ambiguous about the encoding of
passwords.
In practice, we expect most passphrases to be UTF-8-encoded, but if
the incoming passphrase is in fact a bytestring, we ought to be able
to handle it correctly.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
distutils is going away in python 3.12. LooseVersion() wasn't really
being used for anything particularly useful. The strings that were
returned by the openssl backend for the cryptography module, or the
GPGME "engine" version were both just being replayed later as strings
anyway.
So, keep them in string form. If future work needs to do things like
compare them, apparently packaging.version contains classes that might
be better-maintained going forward.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
pytest-order contains a fix for parameterized tests in 1.0, but
that version dropped support for Python 3.5. This patched version
runs on Python 3.5 and has all the other updates in pytest-order 1.0.
A setup.cfg project metadata section is only ever parsed by setuptools,
and thusly does not need to specify that it depends on having setuptools
installed (it is already specified in the pyproject.toml)
Wheel is not required either, since it is only actually used by the
pyproject.toml specified build backend, and wheel is already specified
in the pyproject.toml
pyproject.toml build-requires is intended to specify the basic
requirements for acquiring a usable instance of the build backend. These
packages are dependencies of PEP 517.
setup_requires is intended only for additional project-specific packages
needed in addition to the build backend. These packages are dependencies
of setuptools.setup()
Example difference: wheel is required in order to create a wheel,
pyproject.toml specifies the creation of a wheel. wheel is NOT required
(and is not used at all) in order to run `python setup.py install`,
which does not read pyproject.toml at all.
