Default require_ems based on CryptoProvider FIPS status - #3034
Merged
Merged
Conversation
djc
reviewed
Apr 21, 2026
janrueth
force-pushed
the
fips-require-ems-provider
branch
from
April 21, 2026 09:45
6209b49 to
32168e4
Compare
Previously, require_ems was defaulted solely based on cfg!(feature = "fips"), which is a compile-time check tied to the fips cargo feature. The fips feature unconditionally pulls in aws-lc-rs as the cryptographic provider, making it impossible for third-party FIPS-compliant CryptoProvider implementations (e.g., those backed by BoringSSL) to get correct FIPS policy defaults without also pulling in aws-lc-rs — which may conflict with their own crypto backend. This change also considers the runtime CryptoProvider::fips() status when defaulting require_ems in both ClientConfig and ServerConfig builders. If the configured provider reports itself as FIPS-compliant, require_ems is now automatically set to true, ensuring that ClientConfig::fips() and ServerConfig::fips() return the correct result without requiring the fips cargo feature. This is backward-compatible: existing users of the fips feature see no behavior change, while third-party providers now work correctly out of the box.
janrueth
force-pushed
the
fips-require-ems-provider
branch
from
April 21, 2026 09:48
32168e4 to
7361899
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## rel-0.23 #3034 +/- ##
=========================================
Coverage 95.29% 95.29%
=========================================
Files 97 97
Lines 21852 21854 +2
=========================================
+ Hits 20823 20825 +2
Misses 1029 1029 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Benchmark resultsInstruction countsSignificant differencesClick to expand
Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Memory usageKey:
Significant differencesThere are no significant memory usage differences Additional informationCheckout details:
|
ctz
approved these changes
Apr 28, 2026
Member
|
Published in 0.23.40 -- thanks! |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Previously, require_ems was defaulted solely based on cfg!(feature = "fips"), which is a compile-time check tied to the fips cargo feature. The fips feature unconditionally pulls in aws-lc-rs as the cryptographic provider, making it impossible for third-party FIPS-compliant CryptoProvider implementations (e.g., those backed by BoringSSL) to get correct FIPS policy defaults without also pulling in aws-lc-rs — which may conflict with their own crypto backend.
This change also considers the runtime CryptoProvider::fips() status when defaulting require_ems in both ClientConfig and ServerConfig builders. If the configured provider reports itself as FIPS-compliant, require_ems is now automatically set to true, ensuring that ClientConfig::fips() and ServerConfig::fips() return the correct result without requiring the fips cargo feature.
This is backward-compatible: existing users of the fips feature see no behavior change, while third-party providers now work correctly out of the box.