Stop bumping go directive unless necessitated by other dependencies

[kaovilai]

This repo by itself should not be enforcing minimum on other repositories importing it. Stop spreading "minimum virus"

toolchain version used will be defined outside of go.mod ideally, such as by installing a newer compatible go toolchain to ci/cd/development env.

Failing that, toolchain directive should be used instead of go directive for bumping versions to not cascade minimum versions to importing dependencies.

toolchain directive, in contrast to the go directive, applies only to the current module (the one defined by the go.mod file). It suggests the toolchain to be used when in that very module, and doesn't propagate to other modules.

High profile repos that have removed/reduced minimum go patch version per user requests

• deps: Remove Go minor version from go.mods grpc/grpc-go#7831 motivation

Being proactive to prevent following from reoccuring

• deps: Remove Go patch version from go.mods kopia/kopia#4292
• Do not set minimum go toolchain version in release branches. vmware-tanzu/velero#8397
• Bump github.com/vmware-tanzu/velero from 1.14.0 to 1.15.0 kubevirt/kubevirt-velero-plugin#292 (comment)
• Stop bumping go directive unless necessitated by other dependencies sdk#147

[kaovilai]

@kaovilai ➜ /workspaces/apko (main) $ go mod graph | grep [email protected]
chainguard.dev/apko [email protected]
chainguard.dev/[email protected] [email protected]
chainguard.dev/[email protected] [email protected]
[email protected] [email protected]
k8s.io/[email protected] [email protected]
sigs.k8s.io/[email protected] [email protected]

Nothing in this repo necessitated 1.23.1. In fact, it is shown that the lowest required by other deps is 1.23.1 as required by chainguard.dev/[email protected]

[xnox]

Often there are CVEs in the standard library and the only way to enforce remediation of them in any builds is to bump the version number.

At Chainguard, we do no support building binaries with known CVEs.

[kaovilai]

The standard libraries used to build are based on toolchain setting. go directive is the wrong way to go because it affects importing modules.

golang/go#70853 (comment)

Please see https://go.dev/doc/toolchain#:~:text=Go%20toolchain%20selection%C2%B6

go mod's go directive is the wrong way to go.

If your ci system lacks ability to specify the correct go version to use outside of go.mod file (my preference), use toolchain directive instead please.

[kaovilai]

You do not have to build binaries with known CVEs AND force importing dependencies (those outside of chainguard) to have higher minimum versions.

Everyone including the importing modules can fix standard library CVEs through go cli updates etc WITHOUT commiting change to go.mod file.

[kaovilai]

@xnox Here are some other examples of other repos who won't "support building binaries with known CVEs." as well.

sigstore/rekor#2323
google/go-github#3423

A CVE might affect go1.20.1 go1.22.2
and if its fixed in 1.20.2 and 1.22.3 then
the importing project should have their own autonomy whether they want to up to 1.20.2 or 1.22.3.

The current go directive minimum bump here forces importers to use 1.22.3 rather than just using also fixed 1.20.2

[kaovilai]

Go Directive Minimum version bump should be for new language features, not CVEs imo. There are enough of us with this requirement that several repos are accepting and relaxing the minimum go version.

[imjasonh]

@kaovilai you're right, there's no practical reason we need to so aggressively bump the go version in go.mod.

However, I don't think it's that harmful to do so, and (unfortunately) we and other projects use that version to drive actions/setup-go to tell it which version of Go to install when building and testing (ref)

Unless/until setup-go supports a go-version: latest or something that we can easily use to always get the latest version of Go, I don't see us changing our strategy for updating the go version in go.mod.

Thanks for the feedback.

[kaovilai]

However, I don't think it's that harmful to do so, and (unfortunately) we and other projects use that version to drive actions/setup-go to tell it which version of Go to install when building and testing (ref)

As I have suggested, at minimum, if you require version to be specified in go.mod, use toolchain directive.

Failing that, toolchain directive should be used instead of go directive for bumping versions to not cascade minimum versions to importing dependencies.

like so.

go 1.22

toolchain go1.22.9

Unless/until setup-go supports a go-version: latest or something that we can easily use to always get the latest version of Go, I don't see us changing our strategy for updating the go version in go.mod.

  - uses: actions/setup-go@v5
    with:
      go-version: 'stable'

per https://github.com/actions/setup-go/#:~:text=%2D%20uses%3A%20actions/setup%2Dgo%40v5%0A%20%20%20%20with%3A%0A%20%20%20%20%20%20go%2Dversion%3A%20%27stable%27

[kaovilai]

@imjasonh please let me know if above info helps in solving your requirement.

[xnox]

@kaovilai

Trying to do what you asked for

$ go mod tidy -go=1.17
go: chainguard.dev/[email protected] requires [email protected], but 1.17 is requested

(And also set toolchain go1.23.4) and it doesn't work.

sdk is partially derived from private code; so will need to look into specifying "go + toolchain" there too, before this can make it here.

[kaovilai]

@kaovilai ➜ /workspaces/apko (main) $ go get [email protected] [email protected] && go mod tidy && cat go.mod

module chainguard.dev/apko

go 1.23.3

toolchain go1.23.4

Just did this in github workspace.

[kaovilai]

fyi once you move to setup-go go-version: stable you can remove the toolchain line.

[xnox]

@kaovilai ➜ /workspaces/apko (main) $ go get [email protected] [email protected] && go mod tidy && cat go.mod

module chainguard.dev/apko

go 1.23.3

toolchain go1.23.4

Just did this in github workspace.

sure, but this is of limited value. given that weekly releases of sdk will continue to bump go version; and once that dep is bumped here; we would be virtually back to chasing latest go version here as well.

[kaovilai]

You would have to do the same with SDK. SDK don't need go directive bump all the time..

Once that happens, your go.mod file won't need to change until you actually bump non-go dependencies or you need new language features.

[kaovilai]

your go line will stay the same. leave the version bumping for stdlib CVEs to setup-go version: stable

[kaovilai]

The value at minimum long term is you no longer have to PR as a mechanism of getting a newer go builds. Trigger/Schedule workflows will always use latest.

[xnox]

@kaovilai i also think this request is slightly missplaced. as i think we are inheriting this from our dependencies; and we are in ripple effect with circular imports and thus circular go directive bumps.

Are you going to popularize this ripple globally?

[kaovilai]

I get it if its a dep outside of chainguard's control. So far, go mod graph results say otherwise.

I am only reaching out to repos based on deps my projects are importing directly/indirectly. Many repos already managed relax go minimum as I have highlighted in this issue.

I am advocating on behalf of other users of our projects, namely: kubevirt/kubevirt-velero-plugin#292 (comment)

[kaovilai]

Per my earlier comment bumps in this repo were in fact driven by this repo itself, not other deps.

Specifically, only chainguard.dev/apko has dep of [email protected] from the go mod graph grep [email protected] output as an example. Everything else have lower minimum.

[kaovilai]

You will eventually inherit a newer minimum from dependencies that also misunderstood go.mod go directive yes, but this repo itself should try to be good golangtizens by not adding to the issue.

[xnox]

I am advocating on behalf of other users of our projects, namely: kubevirt/kubevirt-velero-plugin#292 (comment)

i am not seeing chainguard.dev imports there, which projects are impacted that depend on chainguard.dev/apko and what are their current min go directives? where abouts are you importing apko?

[kaovilai]

That repo is the initial request that sparked my advocacy for this issue.

Regarding apko specifically, some of the projects I import have go minimum as a result of apko.

Specifically containers/image#2664 enforced 1.22.6 from

containers/image
❯ go mod graph | grep [email protected]  
github.com/sigstore/[email protected] [email protected]

So I hunt down fulcio's minimum for any repos pinning non zero go directive for repos contributing to this problem
https://github.com/sigstore/fulcio/tree/v1.6.4

@kaovilai ➜ /workspaces/fulcio (5237979) $ go mod graph | grep [email protected]
github.com/sigstore/fulcio [email protected]
chainguard.dev/[email protected] [email protected] <--
github.com/letsencrypt/[email protected] [email protected]
github.com/sigstore/[email protected] [email protected]
github.com/sigstore/sigstore/pkg/signature/kms/[email protected] [email protected]
github.com/sigstore/sigstore/pkg/signature/kms/[email protected] [email protected]
github.com/sigstore/sigstore/pkg/signature/kms/[email protected] [email protected]
github.com/sigstore/sigstore/pkg/signature/kms/[email protected] [email protected]
[email protected] [email protected]
@kaovilai ➜ /workspaces/fulcio (5237979) $ 

Here we first encounter chainguard induced minimum of 1.22.5 in sdk v0.1.23

So I went and check if chainguard-dev/sdk/tree/main exhibit this non zero minimum

@kaovilai ➜ /workspaces/sdk (main) $ go mod graph | grep chainguard.dev/sdk | grep go@1.
chainguard.dev/sdk [email protected]
@kaovilai ➜ /workspaces/sdk (main) $ go mod graph | grep [email protected]
chainguard.dev/sdk [email protected]
chainguard.dev/[email protected] [email protected]
chainguard.dev/[email protected] [email protected]
[email protected] [email protected]
k8s.io/[email protected] [email protected]
@kaovilai ➜ /workspaces/sdk (main) $ 

Sure enough, chainguard-dev/sdk/tree/main has a non minimum required go directive of 1.23.3 where the absolute minimum possible is 1.23.2 as required by

chainguard.dev/[email protected] [email protected]

So for chainguard-dev/sdk/tree/main to drop minimum to 1.23.0 or 1.23, one needs to fix following

• chainguard.dev/[email protected] [email protected]
• chainguard.dev/[email protected] [email protected]

[kaovilai]

So TL;DR is, Any kind of SDK should try to minimize minimum go version required to build.

A library should not be forcing importers to bump versions without basis.

As mentioned in https://github.com/grpc/grpc-go/pull/7624#discussion_r1757159186, grpc-go being a library should not specify a patch version.

Your SDK have minimums coming from apko in main branch, so I am proactively notifying so you are aware that go directive should not be bumped. If you don't have non go.mod alternative to enforce a go toolchain version used, that you please use toolchain directive as intended by go authors which is meant to enforce version used to compile code (and fix CVEs), not go directive, which is a construct for language version compatibility, not security fixes.

Ideally you won't need toolchain specified/bumped either if you just have #1478 fixed