Closed mparuszewski closed 2 years ago
Hi @mparuszewski,
I gave your links a read to see if building FIPS 140 compliant applications has gotten any easier (I haven't tried to do this in a few years). It's still a pretty heavy lift it looks like.
We would not shy away from patches that allow this build to happen, but we don't currently expect to make building Grype in a FIPS 140 environment a priority for the foreseeable future.
I haven't tried, but it looks like the Red Hat instructions in your above links could result in the binary you are looking for. If you try this and have success we would love to hear about it.
Good luck!
Something else to consider is FIPS 140-2 has been superseded by FIPS 140-3, so if possible, the new version should be targeted. FIPS 140-2 is supported until 2026. https://csrc.nist.gov/Projects/fips-140-3-transition-effort
I haven't tried, but it looks like the Red Hat instructions in your above links could result in the binary you are looking for. If you try this and have success we would love to hear about it.
@joshbressers I've tried with instructions for Red Hat, however it failed as Golang 1.18 is not yet available as go-toolset
(and using 1.17 will fail):
...
• building binaries
• building binary=/opt/app-root/src/grype/snapshot/linux-build_linux_amd64/grype
⨯ release failed after 5.84s error=failed to build for linux_amd64: exit status 1: ../go/pkg/mod/github.com/anchore/syft@v0.51.0/syft/pkg/cataloger/golang/scan_bin.go:4:2: package debug/buildinfo is not in GOROOT (/usr/lib/golang/src/debug/buildinfo)
I've tried with building grype with us-docker.pkg.dev/google.com/api-project-999119582588/go-boringcrypto/golang:1.18.4b7
image:
$ docker pull us-docker.pkg.dev/google.com/api-project-999119582588/go-boringcrypto/golang:1.18.4b7
$ docker run --rm -it us-docker.pkg.dev/google.com/api-project-999119582588/go-boringcrypto/golang:1.18.4b7 bash
# apt-get update && apt-get install docker
# git clone https://github.com/anchore/grype.git
# cd grype && make bootstrap
# make build
# ./snapshot/linux-build_linux_amd64/grype ubuntu:18.04
...
# ./snapshot/linux-build_linux_amd64/grype version
Application: grype
Version: 0.43.0-SNAPSHOT-2c7d4e6
Syft Version: v0.51.0
BuildDate: 2022-07-22T10:25:01Z
GitCommit: 2c7d4e66d47e914b8dd6869593ccc98d2d2022b1
GitDescription: v0.43.0-4-g2c7d4e6
Platform: linux/amd64
GoVersion: go1.18.4b7
Compiler: gc
Supported DB Schema: 4
and it worked fine. however we need to check additionally if this is indeed FIPS-compliant or not. 🤔
👋 Thanks for checking @mparuszewski and showing that these can run on a FIPS-enabled OS.
Right now the team doesn't have enough bandwidth to take on the lengthy task of validating and submitting Grype or Syft for FIPS compliance. I'm going to close this issue for now with the hope of reopening and investigating when we have the time and developer power to get this accomplished.
fwiw, closing this as completed
feels misleading, as does it appearing as something added in the latest release.
@joshsleeper I apologize for this making it onto the release. It was part of our automated changelog generator. We've removed this from the release notes.
Also I don't want there to be any confusion here about this being closed as "completed".
The previous comment still stands for closing this issue for the time being. We will reopen again when we have the intent/time/resources to dedicate to the FIPS process.
@joshsleeper I apologize for this making it onto the release. It was part of our automated changelog generator. We've removed this from the release notes.
no worries at all and hopefully I didn't come off gruff, I just want things to be clear to others who do have FIPS requirements to meet that the way this was closed/reported wasn't quite right.
I'm unsure if the two reasons for closure shown here are still the only options: https://docs.github.com/en/issues/tracking-your-work-with-issues/closing-an-issue
but since the work explicitly wasn't done, I would've chosen the "Close as not planned", or ideally even tagged it as a future work item and left it open!
Background:
FIPS 140-2 is a U.S. government computer security standard used to approve cryptographic modules. Recently we see increased interest in developing and using FIPS-compliant software. It is especially needed when working with the U.S. government or other regulated industries.
What would you like to be added:
It would be great to see a build of grype that is FIPS-compliant.
To make sure grype is FIPS-compliant, we need to build it with Go with crypto libraries that are FIPS-compliant. In the industry BoringSSL fork of Go is used to create FIPS-compliant builds, ie: RKE2, Contour, Konvoy, etc., so we could go with this path or investigate other approaches.
Challenges:
Additional context:
There are multiple articles about the possibility to build go apps that are FIPS-compliant. The main problem that we need to solve is that the app must use FIPS-verified cryptographic libraries. Unfortunately, native golang libraries are not FIPS-verified.
More information: