-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor RC2 support to work in an upcoming cryptography release #4285
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #4285 +/- ##
==========================================
- Coverage 81.99% 81.98% -0.02%
==========================================
Files 349 349
Lines 81889 81897 +8
==========================================
- Hits 67148 67140 -8
- Misses 14741 14757 +16
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the work and PR !
3163ff4
to
b5a68ed
Compare
Looks like the most recent changes are causing failures in our CI right now (16e1372#diff-750e485bcc229105845db52d66b35efca6075324730a92e7b8c921e75b741ccdL3) and also have significantly slowed down testing. Anything we can do there? 😄 |
Hi. Sorry about that, do you have an example of a failing runner? |
@gpotter2 https://github.com/pyca/cryptography/actions/runs/7946618525/job/21694556742?pr=10414 -- it times out after 15 minutes |
Good news, they now run much faster (no timeout!). Bad news, they seem to fail: https://github.com/pyca/cryptography/actions/runs/7946618525/job/21700730313?pr=10414 |
Appears to be failing with
(then subsequent failures are due to the first one) |
On Can the key size here be raised to 1024-bit? If not, you can still load an existing, smaller, key. |
This test is using I'll take a look of how we can work around this, probably by trying to generate the key ourselves or something. |
Hmm, in that case, I think the best solution would be to use a pre-generated (hardcoded) key. |
It bothers me to hardcode the key. I'd prefer as much as possible to keep the SSLv2-TLS1.0 implementation in a working, 'per-spec' state, as nowadays there aren't many implementations available that still support those old algorithms (yet they're still encountered in the wild). Do you mind if I 'fix' this by adding a hack that calls |
I can't promise that will work forever (and it won't work on older pyca/cryptography), but for now it will work, and if we do change it, our CI will catch it. |
Okay, that works. See #4290. Tested with cryptography's main and it seems to be working, so I'll merge it once the tests pass. |
Ooops, I don't think this should have been closed :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR looks good but currently doesn't work against cryptography's main, because of the GetCipherByName
import at the beggining of the file. You likely want to move it in the < 43.0
section
b5a68ed
to
21736c4
Compare
@gpotter2 Fix pushed (and also rebased against master once more) 😄 |
The RC2-40 test fails for me locally on our |
Okay, thanks. |
21736c4
to
a6811b2
Compare
Should be fixed now 😄 |
Test failure is in This doesn't look related to the current PR as best I can tell. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again for the PR !
This PR uses the new unreleased (and undocumented)
RC2
support incryptography
(pyca/cryptography#10407), but retains the fallbacks for older versions so that scapy remains compatible. In the next release ofcryptography
we are oxidizing the cipher layer so the non-public APIs currently in use will cease functioning.fixes #4237