[DRAFT] Panic on any FIPS-relevant cryptographic operation#987
[DRAFT] Panic on any FIPS-relevant cryptographic operation#987
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #987 +/- ##
==========================================
- Coverage 95.80% 92.22% -3.58%
==========================================
Files 61 71 +10
Lines 8143 9446 +1303
Branches 0 9446 +9446
==========================================
+ Hits 7801 8712 +911
- Misses 342 451 +109
- Partials 0 283 +283 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| test_logging = [] | ||
| unstable = [] | ||
| prebuilt-nasm = ["aws-lc-sys?/prebuilt-nasm"] | ||
| panic_on_fips = [] |
There was a problem hiding this comment.
This should almost certainly be a cfg flag rather than a feature, since features are transitive? I don't think we want to let dependencies enable the "panic on fips" mode in binaries?
There was a problem hiding this comment.
So this would be needed when there are two (or more) versions of aws-lc-rs resolved to -- one is desired, the others are not. So we'd need to ensure that the one desired version remains unaffected.
One option might be to check some environment variable in the aws-lc-rs build script, like
AWS_LC_RS_PANIC_ON_FIPS_UNLESS_VERSION=1.11.1, and emit a cargo:rustc-cfg=panic_on_fips only if CARGO_PKG_VERSION != AWS_LC_RS_PANIC_ON_FIPS_UNLESS_VERSION.
There was a problem hiding this comment.
I was assuming it would be something like, --cfg aws-lc-panic-unless-version="1.11" (and presumably patch version bumps are still ok, idk).
But ENV works too, anyway main point is, seems sketchy as a (transitive from dependencies) cargo feature flag.
3 participants
Issues:
Resolves #ISSUE-NUMBER1
Addresses #ISSUE-NUMBER2
Description of changes:
Describe current behavior and how your code changes that behavior. If there are no issues this pr is resolving, explain why this change is necessary.
Call-outs:
Point out areas that need special attention or support during the review process. Discuss architecture or design changes.
Testing:
How is this change tested (unit tests, fuzz tests, etc.)? Are there any testing steps to be verified by the reviewer?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.