You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These scanners seem to be comparing against the version 0.0.0 because this is what is listed in go.mod. In reality, the SHA 50e191c183e2 is associated with version 1.17:
$ git clone https://github.com/istio/istio.git
$ cd istio
$ git log 50e191c183e2
commit 50e191c183e29b61ee1be034760e173e27e5f8fd (origin/release-1.17)
Author: Istio Automation <istio-testing-bot@google.com>
Date: Mon Nov 27 08:59:33 2023 -0800
Automator: update proxy@release-1.17 in istio/istio@release-1.17 (#47981)
commit aea0144e18b42decd8670499ebd569da8845275e
Author: Istio Automation <istio-testing-bot@google.com>
Date: Wed Nov 22 11:53:24 2023 -0800
Update BASE_VERSION to 1.17-2023-11-22T19-02-41 (#48004)
A member of the GCP Container Registry scanner team did some investigation and explained the following:
Go module versions are resolved by using repository tags for each version, so e.g. github.com/gorilla/mux v1.8.0 resolves to the tagged release at https://github.com/gorilla/mux/tree/v1.8.0.
If you look at the Go module reference (https://go.dev/ref/mod#versions), you will see that the versioning syntax for Go packages is vX.Y.Z[-optional-suffix].
Now, if you look at the source repo for istio.io/istio at https://github.com/istio/istio, you will see that they are tagged in the format X.Y.Z (missing the prefix v).
This means that the Go toolchain will not recognize it as an actual version and treats the entire module as if it's in a pre-release state (see https://go.dev/doc/modules/version-numbers#in-development), which is how you get the automatically generated v0.0.0-[timestamp]-[commit hash] versions in your go.mod file.
This isn't necessarily an issue in and of itself if the module is truly in a pre-release state, but it seems the issue is that vulnerabilities are being reporting on Github based on the "real" version numbers (e.g. < 1.11.7 in GHSA-856q-xv3c-7f2f) rather than the pre-release version numbers that are being used by the Go toolchain.
They suggested the two following solutions:
istio.io/istio needs to fix their version tags so that they are recognized by the Go toolchain properly
OR they need to report vulnerabilities to the Github Advisory DB using the pre-release versioning scheme
Ask
Are either of these two solutions feasible? Is there a reason why the v prefix is not currently being used?
Personally, I think adding the v prefix makes more sense since it would allow proper recognition by the Go toolchain.
Version
All
Additional Information
I found #14770 which includes a doc mentioning the versioning would include vX.Y.Z (notice v prefix) but the tags don't seem to be using this--only the "Main development work on the master branch" section does not use a v prefix.
The text was updated successfully, but these errors were encountered:
Is this the right place to submit this?
Bug Description
Problem
Our team uses istio directly as a dependency in Golang. Our
go.mod
contains the following:Vulnerability scanners like TwistLock and the one from GCP Container Registry report the following CVEs:
These scanners seem to be comparing against the version
0.0.0
because this is what is listed ingo.mod
. In reality, the SHA50e191c183e2
is associated with version1.17
:A member of the GCP Container Registry scanner team did some investigation and explained the following:
They suggested the two following solutions:
Ask
Are either of these two solutions feasible? Is there a reason why the
v
prefix is not currently being used?Personally, I think adding the
v
prefix makes more sense since it would allow proper recognition by the Go toolchain.Version
Additional Information
I found #14770 which includes a doc mentioning the versioning would include
vX.Y.Z
(noticev
prefix) but the tags don't seem to be using this--only the "Main development work on the master branch" section does not use av
prefix.The text was updated successfully, but these errors were encountered: