Closed ramanNarasimhan77 closed 5 months ago
Thanks @ramanNarasimhan77 , so unfortunately there still isn't a standardized way of embedding the version when building a go binary; however, syft does make an attempt at retrieving the version from common known patterns in the ldflags. We can take a look to see if there are adjustments we can make that would figure it out for gitea as well
@westonsteimel
We found some more CVEs reported incorrectly in gitea by grype due to version issue. Consolidated the whole list.
CVE-2018-15192/GHSA-fg3x-rwq9-74cw - https://nvd.nist.gov/vuln/detail/CVE-2018-15192 CVE-2018-18926/GHSA-hf6f-jq25-8gq9 - https://nvd.nist.gov/vuln/detail/CVE-2018-18926 CVE-2021-45330/GHSA-pg38-r834-g45j - https://nvd.nist.gov/vuln/detail/CVE-2021-45330 CVE-2021-45331/GHSA-hfmf-q69j-6m5p - https://nvd.nist.gov/vuln/detail/CVE-2021-45331 CVE-2022-30781/GHSA-p5f9-c9j9-g8qx - https://nvd.nist.gov/vuln/detail/CVE-2022-30781 CVE-2022-0905/GHSA-jr9c-h74f-2v28 - https://nvd.nist.gov/vuln/detail/CVE-2022-0905 CVE-2022-27313/GHSA-g7p7-x6w7-w6qg - https://nvd.nist.gov/vuln/detail/CVE-2022-27313
Syft is finding two different go executables that it considers copies of code.gitea.io/gitea
, and assigning different versions to them.
/app/gitea/gitea
is found and reported as version v1.16.7
/usr/local/bin/environment-to-ini
is found and reported as version (devel)
.The file at /usr/local/bin/environment-to-ini
is indeed a Go executable, and mentions gitea in its help text.
I copied that file into its own dir and ran syft -q dir:.
to see what packages syft finds:
NAME VERSION TYPE
code.gitea.io/gitea (devel) go-module
command-line-arguments (devel) go-module
github.com/cpuguy83/go-md2man/v2 v2.0.1 go-module
github.com/gobwas/glob v0.2.3 go-module
github.com/golang-jwt/jwt/v4 v4.3.0 go-module
github.com/json-iterator/go v1.1.12 go-module
github.com/kballard/go-shellquote v0.0.0-20180428030007-95032a82bc51 go-module
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd go-module
github.com/modern-go/reflect2 v1.0.2 go-module
github.com/russross/blackfriday/v2 v2.1.0 go-module
github.com/unknwon/com v1.0.1 go-module
github.com/urfave/cli v1.22.5 go-module
golang.org/x/crypto v0.0.0-20220411220226-7b82a4e95df4 go-module
golang.org/x/text v0.3.7 go-module
gopkg.in/ini.v1 v1.66.2 go-module
strk.kbt.io/projects/go/libravatar v0.0.0-20191008002943-06d1c002b251 go-module
Hi @ramanNarasimhan77,
Since this was reported, there's been some effort to better identify Go main module versions. I believe the original issue is fixed:
$ grype -q gitea/gitea:1.16.7 | grep -e GHSA-jr9c-h74f-2v28 -e CVE-2022-0905 -e NAME
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
Is there anything else we should be checking for, or can this be closed? Thanks!
Hi @willmurphyscode
Thanks for letting me know that the original issue has been fixed. I believe this ticket can be closed.
Thanks Raman
What happened:
I am using
gitea/gitea:1.16.7
image in my application. Version from the binary within the Image is 1.16.7 as shown belowGrype is however detecting the version as "(devel)" and hence marking it as vulnerable to a CVE applicable to versions older than 1.16.4.
What you expected to happen:
Grype should detect the correct Go binary app version.
How to reproduce it (as minimally and precisely as possible):
Demonstrated above
Anything else we need to know?:
Environment:
Output of
grype version
:OS (e.g:
cat /etc/os-release
or similar):