Improve forward compatibility #442
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These tests are pulled from the OpenPGP Interoperability Test Suite, in particular from those tests tagged "forward-compat": https://tests.sequoia-pgp.org/?q=forward-compat These failures make it difficult to use PGPy in an OpenPGP ecosystem that can evolve, because PGPy will complain about OpenPGP objects that contain something it doesn't understand, even though the rest of the message is otherwise comprehensible and usable. See Justus Winter's message to openpgp@ietf.org describing his concerns: https://mailarchive.ietf.org/arch/msg/openpgp/QUiEKx3PQeJOXnkcvvnuHpv739M I've selected specific examples that PGPy is known to currently fail with.
|
These changes also include some (hopefully positive) side effects:
|
This was referenced Jun 14, 2023
dkg
force-pushed
the
compat-tests
branch
2 times, most recently
from
b61a02f
to
4915ce0
Compare
a PGPMessage object can contain more than one signature. Detached signatures should also be able to handle having more than one signature. https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-09.html#name-detached-signatures says: > These detached signatures are simply one or more Signature packets > stored separately from the data for which they are a signature. A PGPSignatures object makes the most sense to represent such a thing. Closes: SecurityInnovation#197
The cryptography module supports encoding and decoding these signatures directly, so no need for pyasn1 or the custom ASN1 decoder to translate between the OpenPGP format and the RFC 3279 format.
OpenSSL 1.0.2 is ancient at this point -- Brainpool is part of the standard distribution. At any rate, we need 1.1.0 for X25519 and 1.1.1 for Ed25519. And python's cryptography module has supported Brainpool since version 2.2 (also ancient). Registering subclasses with the cryptography module is complicated across versions (see pyca/cryptography#7234 which removed register_interface), but we don't need any of that functionality as long as we depend on non-ancient modules. At the same time, we don't need pyasn1 any longer if we just treat the OID as a bytestring label. As this also drops all the shenanigans around cryptography.utils.register_interface, we can also say it Closes: SecurityInnovation#402
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These tests are pulled from the OpenPGP Interoperability Test Suite,
in particular from those tests tagged "forward-compat":
https://tests.sequoia-pgp.org/?q=forward-compat
These failures make it difficult to use PGPy in an OpenPGP ecosystem
that can evolve, because PGPy will complain about OpenPGP objects that
contain something it doesn't understand, even though the rest of the
message is otherwise comprehensible and usable.
See Justus Winter's message to openpgp@ietf.org describing his
concerns:
https://mailarchive.ietf.org/arch/msg/openpgp/QUiEKx3PQeJOXnkcvvnuHpv739M
I've selected specific examples that PGPy is known to currently fail with.
This series should make all the new tests pass, which should also improve the score of PGPy on the interop test suite.