POC of replacing boringcrypto with Go's native FIPS-140-3 module

[mjlshen]

Warning

Disclaimer: How boilerplate sets up FIPS compliance should definitely follow Red Hat guidelines. I don't know what they are. I am just making this MR to raise awareness of this configuration and its brief history.

• GOEXPERIMENT=boringcrypto + the "crypto/tls/fipsonly" library, which required CGO_ENABLED=1 was initially used. The cgo requirement necessitated a swap from ubi*-micro --> ubi*-minimal images.
• Then there was GOEXPERIMENT=strictfipsruntime, added in Use GOEXPERIMENT=strictfipsruntime #298 when Red Hat was supporting an internal fork of Go, this was deprecated and removed in OSD-29374: Drop unsupported strictfipsruntime GOEXPERIMENT for Go 1.23 #516
• Nowadays, Go natively supports FIPS starting in Go 1.24 (without requiring cgo!) with borincrypto slated to be removed in a future release. Boilerplate was already updated for Go 1.24 in SREP-144: Switch to UBI9 and install Go 1.24 #582

I think this makes FIPS compliance easier than ever - especially the removal of the cgo requirement should allow usage of ubi*-micro images again if there's a desire for that (fewer CVEs to manage!).

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mjlshen
Once this PR has been reviewed and has the lgtm label, please assign joshbranham for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mjlshen]

/hold

This shouldn't be merged. It should be worked on internally if important.

[joshbranham]

This is blocked internally for HCM security to confirm that FIPS-140-3 is good to go. I will follow up with them.

[tonytheleg]

I asked about this a long time ago when the blog first dropped, so it may not be valid information anymore. As I understand it, the FIPS in native Go is still "In process" and is not fully "approved" so there may be some legal/compliance-y back and forth on what that means. +1 to definitely discussing with internal compliance/security teams + the FIPS folks before any major changes. Lately I've been using go-toolset (installed via package manager) for FIPS builds which is essentially Red Hat's fork of Go with all the OpenSSL bits to ensure FIPS compliance.