Open learnitall opened 1 month ago
Syft is picking up that boring crypto was used, however, it's not being packed into the version string:
syft ./mybin -o json | jq
Snippet of the JSON output for the package that represents the go module (localhost
in this case):
{
"id": "c9dc90c23223383a",
"name": "localhost",
"version": "(devel)",
"type": "go-module",
"foundBy": "go-module-binary-cataloger",
"locations": [
{
"path": "/example",
"accessPath": "/example",
"annotations": {
"evidence": "primary"
}
}
],
"licenses": [],
"language": "go",
"cpes": [],
"purl": "pkg:golang/localhost@(devel)",
"metadataType": "go-module-buildinfo-entry",
"metadata": {
"goBuildSettings": [
{
"key": "-buildmode",
"value": "exe"
},
{
"key": "-compiler",
"value": "gc"
},
{
"key": "CGO_ENABLED",
"value": "1"
},
{
"key": "CGO_CFLAGS",
"value": ""
},
{
"key": "CGO_CPPFLAGS",
"value": ""
},
{
"key": "CGO_CXXFLAGS",
"value": ""
},
{
"key": "CGO_LDFLAGS",
"value": ""
},
{
"key": "GOARCH",
"value": "amd64"
},
{
"key": "GOEXPERIMENT",
"value": "boringcrypto"
},
{
"key": "GOOS",
"value": "linux"
},
{
"key": "GOAMD64",
"value": "v1"
}
],
"goCompiledVersion": "go1.23.2",
"architecture": "amd64",
"mainModule": "localhost",
"goCryptoSettings": [
"boring-crypto"
],
"goExperiments": [
"boringcrypto"
]
}
},
Take note that there are goExperiments
and goCryptoSettings
that indicate boring crypto is enabled here.
I realize that you're expectations are probably derived from the go tooling output:
go version -m ./mybin
/tmp/example: go1.23.2 X:boringcrypto
path localhost
mod localhost (devel)
build -buildmode=exe
build -compiler=gc
build CGO_ENABLED=1
build CGO_CFLAGS=
build CGO_CPPFLAGS=
build CGO_CXXFLAGS=
build CGO_LDFLAGS=
build GOARCH=amd64
build GOEXPERIMENT=boringcrypto
build GOOS=linux
build GOAMD64=v1
Where the golang version string is go1.23.2 X:boringcrypto
. I don't think we should make the version string for the package literally be this value, since this would make downstream use cases more difficult. That being said, though this version string is not semver (note the leading go
value) we could treat this auxiliary information as semver does: go1.23.2+X:boringcrypto
(note the +
). Semantically downstream use cases should strip the auxiliary data after the +
.
I'm on the fence for this change, but wanted to put it out there to see what folks think. In the meantime does the knowledge that the JSON output has what you need help you out @learnitall ?
Ok that makes sense @wagoodman, thank you for the detailed explanation. The knowledge of the JSON output having the crypto details is helpful, as I honestly thought this was a bug, but it doesn't address the use case I'm approaching this from. I apologize for not being specific enough earlier, I can open a new issue if that would be more helpful.
My main goal is to have the crypto options of a Go binary show up within the sdpxjson
output. I'd like to generate an SPDX SBOM from a Docker image that can demonstrate that the contained Go binaries use boringcrypto with the FIPS-only option set. Otherwise, the SBOM can't attest to the Go binaries using FIPs compliant crypto.
Adding the GOEXPERIMENT
information into the version string would be helpful, but I don't think it would be useful for usage within an SBOM because: (1) it doesn't contain information regarding setting the FIPs-only option and (2) it's possible to build a binary with GOEXPERIMENT=boringcrypto
that still uses the standard crypto libraries (ie if CGO_ENABLED=0
). I'm stilling learning the SPDX format, but maybe the PackageSourceInfo field would be appropriate? If we figure out a way this could work, I can submit a PR with the implementation.
Again, my apologies for not being specific enough. Thank you for your help and patience!
What happened:
I build a Go binary using the boringcrypto Go Experiment, however a Syft scan showed the experiment as not being used. This happens regardless of if
crypto/tls/fipsonly
is imported.What you expected to happen:
The Go standard library version would contain some sort of reference to the boringcrypto experiment being used.
Steps to reproduce the issue:
Create an example binary. I chose to use this one, which I found via https://github.com/golang/go/issues/68588.
Compile the binary using
GOEXPERIMENT=1 CGO_ENABLED=1
:go tool nm
to verify that the boringcrypto experiment was applied:Anything else we need to know?:
The kind of output I was expecting to see was something like:
Environment:
syft version
:The version of Syft that I used was one that I built today off of commit https://github.com/anchore/syft/commit/01de99b25304ec95197c00b21d698f127b31a887 (v1.13.0)
cat /etc/os-release
or similar):