Boring crypto #8
Conversation
There was a problem hiding this comment.
Some further work will be required in the build pipeline to make sure that the correct image is used. It appears that 1.20 supports arm64 and is controlled by the simpler GOEXPERIMENT=boringcrypto (introduced in 1.19) so it makes sense to align the implementation.
Is there a jira for this change? I feel there are implementation issues to resolve before this PR can be merged. Assuming FIPS-140 as the standard to be met, there is more to it than the build image as it views the hardware, OS and application code as a system.
| tag: el7 | ||
| - gover: "1.15" | ||
| debver: buster | ||
| debver: "-buster" |
There was a problem hiding this comment.
- image: "goboring/golang"
debver: ""
gover: "1.16.7b7"
tag: fips
1.16.7b7 is not a value in the gover matrix. So this rule will not match.
There was a problem hiding this comment.
1.16.7b7 is not a value in the gover matrix. So this rule will not match.
Well it is a version, it just have 2 layers of versioning. 1.16.7 is version of go, and b7 is seventh patch of boringcryto.
So better add new variable like "GO_VERSION_SUFFIX"?
There was a problem hiding this comment.
Yes 1.19+ have boringcrypto embedded, but we moved it to 5.1, so for now 1.16 is what we need.
Goal is to have a PoC first. And yes OS/Docker image hardening is part of FIPS work, BUT, we may just say customer to install packages or build docker by themselves (even if on top of our image).
Added Go 1.16 compiled with boringcrypto OpenSSL
https://github.com/golang/go/blob/dev.boringcrypto.go1.17/misc/boring/README.md
https://hub.docker.com/layers/goboring/golang/1.16.7b7/images/sha256-ad86974b2b260afa11293748b6c1e0fe0edbeb5874f8850d108cdcdf0a5795c1?context=explore
It will be needed to have our binaries FIPS compatible.
Essentially it limits all crypto and hashing algorithms only to the ones which are supported in FIPS standard.
Also this version has limitations, only: GOOS=linux, GOARCH=amd64.