Update to go 1.24.3

[pkoutsovasilis]

What is the problem this PR solves?

This PR updates the Go language version used in the project from 1.24.1 to 1.24.2 across all relevant modules (go.mod, dev-tools/go.mod, testing/go.mod).
Keeping the Go version up to date ensures we benefit from the latest bug fixes, performance improvements, and security patches.

Depends on:

• Revert "Remove context.background and variable copy from test case" #4892

How does this PR solve the problem?

The CI configuration (.ci/bump-golang.yml) was adjusted to correctly detect and update Go versions in all relevant go.mod files.
The go.mod files for the main project, dev tools, and testing were updated to reference Go 1.24.2.
A changelog fragment was added to document this upgrade.

How to test this PR locally

N/A

Design Checklist

• I have ensured my design is stateless and will work when multiple fleet-server instances are behind a load balancer.
• I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.
• I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.

Checklist

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool

Related issues

N/A

[prodsecmachine]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

[pkoutsovasilis]

Lint failures are addressed here

[swiatekm]

What exactly is the benefit of updating the patch version in go.mod files? Is it so it's impossible to build fleet-server with an earlier version?

[pkoutsovasilis]

@swiatekm what's the counter argument here? 🙂 Could you share a little bit more why you feel that having patch versions in go.mod is causing more harm than good?

To begin with, IMO, "recent" Go versions (starting with 1.21 IIRC) started imposing in a way the patch part of the version inside go.mod ref.

To improve forwards compatibility, Go 1.21 now reads the go line in a go.work or go.mod file as a strict minimum requirement: go 1.21.0 means that the workspace or module cannot be used with Go 1.20 or with Go 1.21rc1. This allows projects that depend on fixes made in later versions of Go to ensure that they are not used with earlier versions. It also gives better error reporting for projects that make use of new Go features: when the problem is that a newer Go version is needed, that problem is reported clearly, instead of attempting to build the code and printing errors about unresolved imports or syntax errors.

If we go without any patch version it means that we could compile fleet-server with any go >= 1.24.x. And here is the tricky part of expectation I would say; when we say that we addressed a CVE which is resolved in go 1.24.2, I feel it is safer to make fleet-server compile only with 1.24.2 (and new versions), thus guarantee that the CVE is resolved. Do you feel otherwise? 🙂

[swiatekm]

@swiatekm what's the counter argument here? 🙂 Could you share a little bit more why you feel that having patch versions in go.mod is causing more harm than good?

I don't feel that way. I asked the question because I didn't know.

I don't think there's any counter-argument when it comes to bumping the version due to a high-severity CVE. But you're also making updatecli bump this for every patch version, which might be annoying for local work. Even if Go 1.24.3 is out and we start building release fleet-server binaries with that version, I don't see any harm in contributors continuing to use Go 1.24.2 locally.

[pkoutsovasilis]

I don't think there's any counter-argument when it comes to bumping the version due to a high-severity CVE. But you're also making updatecli bump this for every patch version, which might be annoying for local work. Even if Go 1.24.3 is out and we start building release fleet-server binaries with that version, I don't see any harm in contributors continuing to use Go 1.24.2 locally.

I hear you 🙂 two proposals then:

1. skip bumping the patch version when updatecli is able to tell if there is a high-severity CVE included in new version but for now we bump it
2. we skip bumping it now but we assign an owner of bumping the patch version inside go.mod every-time there is a high-severity CVE that we need to address? do you volunteer?

[swiatekm]

I don't think there's any counter-argument when it comes to bumping the version due to a high-severity CVE. But you're also making updatecli bump this for every patch version, which might be annoying for local work. Even if Go 1.24.3 is out and we start building release fleet-server binaries with that version, I don't see any harm in contributors continuing to use Go 1.24.2 locally.

I hear you 🙂 two proposals then:

1. skip bumping the patch version when updatecli is able to tell if there is a high-severity CVE included in new version but for now we bump it

2. we skip bumping it now but we assign an owner of bumping the patch version inside go.mod every-time there is a high-severity CVE that we need to address? do you volunteer?

Can we leave the update targets in, but only trigger them manually? Then 2 would be very low-maintenance, and I'd be fine taking it up.

[kaanyalti]

I did not see the linting failures, and the comments the came in as I was going through the code before approving. I'm going over them now, but the changes look good to me.

[kaanyalti]

Went through the comments, there isn't much I can add to the discussion. My approval stands.

[pkoutsovasilis]

@swiatekm I believe it's not as simple as leaving just the targets and I am eyeballing mostly this part

  goDefaultVersion-check:
    name: Check if defined golang version differs
    kind: shell
    sourceid: latestGoVersion
    spec:
      command: 'grep -v -q {{ source "latestGoVersion" }} .go-version #'

we always check based on the .go-version and there we always have the patch version. If I leave the existing replacement targets and because of a CVE we have added the patch version in go.mod the existing targets will result in replacing it yet again with a non-patch version. In other words this requires some thinking, wanna create a follow-up issue for what you propose?

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[ebeahan]

Changes LGTM.

If we need to continue the ongoing discuss (#4891 (comment)), I propose creating a separate issue to determine how to approach.

[cmacknz]

Let's move 7.17 up to Go 1.24. No release planned but if there were, that simplifies future Go update backports and we do want the CVE fixes from the latest 1.24.x or 1.23.x there.

[blakerouse]

This looks good to me. I actually like the patch version in there, ensures that on my host I will be matching what is being used by the built binary. Not a strong opinion on it, but I do like that.

[swiatekm]

Since this is apparently what we do in other projects, I'm happy doing it here as well.