-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
Fix legacy crypto support for OpenSSL 3 #61
Conversation
I had run into issues with OpenSSL 3 on macOS. I think I also made a VMWare image of 22.04 for testing. Either way, we should make sure this config is tested via CI. |
Haven't written many tests before so I'm unsure how to do that. Sure, I could write a test case that tries to decrypt something that's only supported by the legacy provider, but that test would then fail if you actually had an environment where the legacy provider is not available. |
I think at this point some info about the legacy module being present (maybe results of Not sure if any of the CI providers have Ubuntu 22.04 yet that we can add for testing, but that should come after a reproducer. |
Right now both before and after this PR all of CI passes, so we just need to make sure we have a failing test that changes to successful. |
Okay, should now be done. On the I also added another CI target for Ubuntu 22.04 with Python 2, just in case. The test case tries to load the "legacy" module the proper way (just load and see if it works, rather than trying to check that before), and if that was successful (= the test case was able to load the legacy module), but |
Anything I still need to do to get this merged, or is this just waiting for review? EDIT: I have embedded a fork of oscrypto into my application with exactly this patch, and multiple people confirmed that this fixes the issue with legacy crypto on Ubuntu 22.04, Fedora 36 and Debian unstable. |
Any update to this PR, @wbond ? |
What's going on with this? This had a PR back on 6 May (coming up on 3 months ago) and nothing's happened. Does Leseratte10 need to do anything else? Right at the bottom of this thread, Github appears to be saying the submission has passed all checks. |
oscrypto just hasn’t bubbled up to the top of my open source priority queue yet. In the meantime, feel free to test this PR out in your stack. |
Thanks for your response. I'm going to use my own fork in the meantime then until this is merged and included in a new release. |
The latest version of oscrypto does not yet support OpenSSL 3, which is used in Ubuntu 22.04, Fedora 36 and a bunch of other newer Linux distributions. When wbond/oscrypto#61 is merged and included in a new release, this change will be reverted.
Yea there is also a Problem installing the Plugin in Calibre with the following messages - (I downloaded the Zip-File from the rep and tried it ) - I have Ubuntu 20.04.4 LTS calibre 4.99.4 embedded-python: False is64bit: True During handling of the above exception, another exception occurred: Traceback (most recent call last): #################################################### Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): Thanks a lot in advance! |
This doesn't really fit into this bug report since it has nothing to do with oscrypto. The bug mentioned here is fixed with the new plugin (which uses a fork of oscrypto). Looking at the version number you're using an old Calibre-5 beta - if you're on Ubuntu, don't install from the repo but directly from calibre-ebook.com. |
Sorry for the delay in getting to this @Leseratte10, but I'm merging this now. Thanks for working on it and your patience! |
Thanks for getting this merged; is there any plans to release this as 1.3.1 or 1.4.0 on PyPi with that fix? I see that "pip install oscrypto" currently still gets you the old broken version of the library. |
There seem to be two bugs in the existing code (as reported in #60 )
A)
OSSL_PROVIDER_available
indicates if a provider is loaded - if it is available to be used. Not if it is installed, as in, available to be loaded. That means, it will always be false as in the default config (at least on Ubuntu 22.04) it's not loaded.You first need to (try to) load the legacy provider, then check if that was successful.
Quoting from the OpenSSL commit message that introduced this function:
B) Once you load any provider (in this case, "legacy"), OpenSSL no longer loads the default provider with all the non-legacy code. You need to load both, one after the other. This bug didn't affect anything in 1.3.0 because due to bug A), the code never actually tried to load the legacy module, at least in my tests.