Revert "refactor: remove unused evp support for md5+sha1 (#5106)" #5118
+129
−109
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.
This reverts commit f3ae011.
Release Summary:
Resolved issues:
related to #5105
Description of changes:
I made this change because my plan for the final state of hash + signing assumed that Legacy signing would still be required for openssl-3.0-fips to use MD5 hashes, so might as well also be kept around for openssl-1.0.2 too. However, I have since found a mistake in my openssl-3.0-fips signing logic and concluded that openssl-3.0-fips will need EVP support for MD5 anyway. With that change, the expected end state of the system has also changed. I updated #5105. In the new version, ALL libcryptos use EVP hashing.
That means that instead of removing the EVP support for MD5+SHA1, I should have removed the Legacy support for MD5+SHA1 (and the Legacy support for all other hash algorithms too).
This PR reverts the old change. We will reuse this openssl-1.0.2-fips logic for both openssl-3.0-fips and openssl-1.0.2.
Testing:
This is a straight revert, so going back to a known good state. Tests should continue to pass.
How do I know it's the RIGHT change? Well my fixed signing logic is working with it locally, but I also thought that before :) Unfortunately unless I push out one giant blob of a PR, out CI might find more mistakes as I publish my incremental PRs and I might have to update previous work again. However, I've given up basically all my "clever" ideas at this point, so I don't actually think anything else can go wrong. We're not doing FIPS 140-3 and we're requiring the Default provider. Any other concessions and openssl-3.0-fips might just be un-supportable.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.