-
Notifications
You must be signed in to change notification settings - Fork 114
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
Add fips-3678 feature #52
Add fips-3678 feature #52
Conversation
...instead of X509_getm_notBefore() and X509_getm_notAfter(). According to https://www.openssl.org/docs/man1.1.0/man3/X509_getm_notBefore.html, "X509_getm_notBefore() and X509_getm_notAfter() are similar to X509_get0_notBefore() and X509_get0_notAfter() except they return non-constant mutable references to the associated date field of the certificate".
This is equivalent according to https://boringssl.googlesource.com/boringssl/+/c947efabcbc38dcf93e8ad0e6a76206cf0ec8072
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.
Can you add a test to .github/workflows/ci.yml
testing that this compiles when --features fips-3678
is set?
We're interested in using this feature in Linkerd. The preceding PR, #24, was a part of this work. This isn't an urgent need, exactly, but it's not something we want to defer indefinitely, either. Is there a path forward for this PR? Is there anything we can do to help? It sounds like the open questions were mostly around the build infrastructure and how to make this build reproducible/self-contained? Is that the primary blocker for this work? Or are there other concerns after that is addressed? Thanks :) |
The version of boringssl that's FIPS-certified doesn't have `X509_set1_notAfter`. The only difference between that and `X509_set_notAfter` is whether they're const-correct, which doesn't seem worth having two different code-paths.
NIST specifies that it needs to be 7.0.1; I originally tried building with clang 10 and it failed. Theoretically this should check the versions of Go and Ninja too, but they haven't given me trouble in practice. Example error: ``` Compiling boring-sys v1.1.1 (/home/jnelson/work/boring/boring-sys) error: failed to run custom build command for `boring-sys v1.1.1 (/home/jnelson/work/boring/boring-sys)` Caused by: process didn't exit successfully: `/home/jnelson/work/boring/target/debug/build/boring-sys-31b8ce53031cfd83/build-script-build` (exit status: 101) --- stdout cargo:rerun-if-env-changed=BORING_BSSL_PATH --- stderr warning: missing clang-7, trying other compilers: Permission denied (os error 13) warning: FIPS requires clang version 7.0.1, skipping incompatible version "clang version 10.0.0-4ubuntu1 " thread 'main' panicked at 'unsupported clang version "cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0": FIPS requires clang 7.0.1', boring-sys/build.rs:216:13 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ```
I opened behrat#1 getting this working a little better without needing an external boring build. |
Now that build.rs checks out the appropriate commit automatically, there's not a strong need to have the version number itself in the feature. We can always add multiple features in the future if we support more than one FIPS-validated version.
Fix up fips integration
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.
Looks good with the BORING_BSSL_INCLUDE_PATH
support added back in - sorry for the noise there.
Oh, also it looks like you need to add clang-7 to the test environment. |
0e74215
to
2e1802a
Compare
These weren't caught until PR CI ran.
2e1802a
to
75462e8
Compare
Thanks for the help @jyn514! I think that addresses all feedback from my original version of the PR, and this looks ready-to-merge to me. |
This PR contains multiple logical commits. The ones before "Add fips-3678" I think can actually stand on their own, and are useful even without FIPS support.
Since some of the APIs are not available in the FIPS-validated version, we must add some conditional-compilation in order to successfully link against the FIPS-validated version of BoringSSL (see the addition in
README.md
for details). This can be controlled with the newfips-3678
feature. The intention of naming the feature this way is that future FIPS-validated versions of BoringSSL can by supported by adding afips-xxxx
feature, while still supporting thefips-3678
for backwards-compatability.