Test fips for Ruby #592
Merged
Test fips for Ruby #592
Conversation
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
Pull Request validationFailed🔴 Failed or pending statuses:
🔴 Review - Missing review from a member (1 required) |
Member
|
[test] |
Member
|
[test] |
Testing Farm results
|
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
3 similar comments
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
1 similar comment
Contributor
Author
|
[test] |
Testing Farm results
|
Contributor
Author
|
[test] |
Pull Request validationFailed🔴 Review - Missing review from a member (1 required) Success🟢 CI - All checks have passed |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Contributor
Author
|
[test] |
Add FIPS test and example application with HTTP. The check is simply executing OpenSSL.fips_mode which returns bool. Based on exit status we can then know whether it failed/succeeded as we expect it to. The app has 4 GET endpoints that executes some OpenSSL capability. 2 of those test symmetric ciphers: * '/symmetric/aes-256-cbc' -- succeeds under FIPS * '/symmetric/des-ede-cbc' -- fails under FIPS 2 of those test digests: * '/hash/sha256' -- succeeds under FIPS * '/hash/md5' -- fails under FIPS The app is prepared so that it tests assumptions of when should what fail, under both FIPS and non-fips environment. These endpoints either return 200 if the case for them succeeded or 5xx for FIPS related failures and 4xx for general failures not accounted for. When a failure happens when it shouldn't, the app also returns backtrace in the response body. A few examples: MD5 succeeds and FIPS is enabled, that's unexpected, returns 500 SHA256 fails in any case, 409 is returned because that shouldn't happen with both FIPS disabled and enabled, something else went wrong. MD5 fails with FIPS enabled, that's desired and expected, returns 200. Since more information is passed within body on response, `curl --fail-with-body` is recommended. 409 is chosen to differentiate 500 returned in cases we might expect. It was chosen firstly as it is "user error", either the code is wrong, or the setup is wrong. For the purpose of building and running the app, an adjustment was made to run_test_application to be able to run a custom named container. Otherwise there is only testapp to be ran and we can have better names.
Contributor
Author
|
@phracek finally got through to something I'd call functioning tests... Ready for review. |
Contributor
Author
|
[test] |
phracek
reviewed
Oct 16, 2025
Member
phracek
left a comment
phracek
left a comment
There was a problem hiding this comment.
I don't understand test_ruby_fips_s2i_app function.
| ct_wait_for_cid "${cid_file}" | ||
| ct_test_response "http://$(container_ip):8080/symmetric/aes-256-cbc" 200 "" | ||
| ct_check_testcase_result $? | ||
| ct_test_response "http://$(container_ip):8080/symmetric/des-ede-cbc" 200 "" |
Member
There was a problem hiding this comment.
Based on your description in pull request:
- '/symmetric/aes-256-cbc' -- succeeds under FIPS
- '/symmetric/des-ede-cbc' -- fails under FIPS - This should fail.
2 of those test digests: - '/hash/sha256' -- succeeds under FIPS
- '/hash/md5' -- fails under FIPS
test_ruby_fips_s2i_app where is enabled FIPS mode This works the same as for FIPs mode and for None FIPs mode? Like this https://github.com/sclorg/s2i-nodejs-container/blob/master/test/test-lib-nodejs.sh#L587
Contributor
Author
There was a problem hiding this comment.
It is checked in code that it fails under FIPS, an exception is rescued. If an exception does NOT occur under FIPS, then the test fails.
Contributor
Author
There was a problem hiding this comment.
I noted it down with those comments that there are ciphers/hashes which are expected to fail and which are expected to pass. If those that should pass raise an exception, that is not expected and the test will fail.
phracek
approved these changes
Oct 16, 2025
Member
phracek
left a comment
phracek
left a comment
There was a problem hiding this comment.
LGTM. Thanks for adding FIPS enabled Ruby container. It brings to customers, that we have a container FIPS compliance.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Worked on mimicking the nodejs approach: sclorg/s2i-nodejs-container#498
The check is simply executing OpenSSL.fips_mode which returns bool.
Based on exit status we can then know whether it failed/succeeded against our expectation.
The app has 4 GET endpoints that executes some OpenSSL capability.
2 of those test symmetric ciphers:
2 of those test digests:
The app is prepared so that it tests assumptions of when should what
fail, under both FIPS and non-fips environment.
These endpoints either return 200 if the case for them succeeded
or 5xx for FIPS related failures and 4xx for general failures not
accounted for. When a failure happens when it shouldn't, the app also
returns backtrace in the response body.
A few examples:
MD5 succeeds and FIPS is enabled, that's unexpected, returns 500
SHA256 fails in any case, 409 is returned because that shouldn't happen
with both FIPS disabled and enabled, something else went wrong.
MD5 fails with FIPS enabled, that's desired and expected, returns 200.
Since more information is passed within body on response,
curl --fail-with-bodyis recommended.409 is chosen to differentiate 500 returned in cases we
might expect. It was chosen firstly as it is "user error", either the code is
wrong, or the setup is wrong.
For the purpose of building and running the app,
and adjustment was made to run_test_application to be able to run a custom
named container.
Otherwise there is only testapp to be ran and we can have better names.