Uh oh!
There was an error while loading. Please reload this page.
PQC support via new pysequoia version - #8011
Conversation
| "psycopg[binary]>=3.3.4,<3.4", # SemVer, not explicitely stated, but mentioned on multiple changes. | ||
| "pyparsing>=3.1.0,<3.4", # Looks like only bugfixes in z-Stream. | ||
| "pysequoia>=0.1.33,<0.2", | ||
| "pysequoia @ git+https://github.com/wiktor-k/pysequoia.git", |
There was a problem hiding this comment.
It's not released yet, just testing the rest of the changes.
7bda8fc to
0d00aeeCompareUsing ephemeral keys turns out to be much faster than downloading keys from fixtures, 0.09s vs 5.38s. The exception is RSA which is slower (keygen is expensive by comparison to other algos) but I'm not adding any tests using RSA here. |
| from pulpcore.pytest_plugin import ( | ||
| KEY_V4_RSA4K_PRIVATE, | ||
| KEY_V6_MLDSA65_ED25519_PRIVATE, |
There was a problem hiding this comment.
Well, OK, we still download the fixture keys here.
Rebase the minimum bound of pysequoia to one which adds support for post-quantum cryptography / RFC 9980. Add tests for gpg_verify function and PQC signing services Assisted-By: Claude Sonnet 4.5
| ] | ||
| @pytest.fixture(params=TEST_KEYS, ids=[k[0] for k in TEST_KEYS], scope="module") |
There was a problem hiding this comment.
I think these tests have some value, because they do test our own API wrapper around pysequoia, but if you think they (or any individual test(s) are) more of a glorified pysequoia unit test, I can drop it.
There was a problem hiding this comment.
Alternatively we can deprecate the gpg_verify function completely and remove it in the next breaking change release, because it's only a thin wrapper around pysequoia anyway, which plugins could just use directly if they wanted to.
There was a problem hiding this comment.
Well, didn't we keep the interface of gpg_verify stable with this change? Then it already won. Why would we remove it?
There was a problem hiding this comment.
It predated having any kind of usable library for this purpose - python-gnupg was kind of a pain to use because you had to set up ephemeral directories all the time - at this point the wrapper is probably not needed.
Of course we did keep the API stable anyway, but that doesn't mean we can't move away from it over the longer term. Question is just whether we ought to mark it deprecated or not.
| "psycopg[binary]>=3.3.4,<3.4", # SemVer, not explicitely stated, but mentioned on multiple changes. | ||
| "pyparsing>=3.1.0,<3.4", # Looks like only bugfixes in z-Stream. | ||
| "pysequoia>=0.1.33,<0.2", | ||
| "pysequoia>=0.1.35,<0.2.0", |
There was a problem hiding this comment.
Do we know about the specific versioning policy here?
There was a problem hiding this comment.
It hasn't been the most consistent. Personally I think it ought to have been a 0.2.0 release given the major changes, but there were no breaking changes at least.
Backport to 3.105: 💚 backport PR created✅ Backport PR branch: Backported as #8025 🤖 @patchback |
Backport to 3.116: 💚 backport PR created✅ Backport PR branch: Backported as #8026 🤖 @patchback |
Rebase the minimum bound of pysequoia to one which adds support for post-quantum cryptography / RFC 9980.
Add tests for gpg_verify function and PQC signing services
Assisted-By: Claude Sonnet 4.5