beats
beats copied to clipboard
elastic
Support Go 1.18
It has been several months since the Go 1.18 release with several 1.18.x minor versions released. It should be safe to upgrade beats and our other repositories to Go 1.18.
The first attempt to update to Go 1.18 revealed at least two broken tests we need to address:
- [ ] https://github.com/elastic/beats/pull/32493
- [ ] https://github.com/elastic/beats/issues/30954
- [x] https://github.com/elastic/beats/issues/30953
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)
Our build automation is also now working well with Go Workspaces. go list -m, when workspaces are in use, returns more than one module and this breaks our scripts.
I did a very quick-and-dirt fix: https://github.com/belimawr/beats/commit/6a3206be5b758d9755091edb24ac58af813c8644. I'm posting it here to document it. Later on I can create an issue better describing the problem.
If 1.18 will be needed, then the golang bump automation needs to be updated to listen any new releases for 1.18:
- https://github.com/elastic/apm-pipeline-library/blob/3102b08c8aed84818d98406d91b40cc3401619ac/.ci/.bump-go-release-version.yml#L36
Similar for the other projects
Fleet-Server is ready for Go 1.18 https://github.com/elastic/fleet-server/pull/1688 Elastic-Agent is ready for Go 1.18 https://github.com/elastic/elastic-agent/pull/797
I will do a followup for the linters.
Talked faster than the ci...
Looking at the Go 1.18 release notes, for the beats test failures we are being affected by:
Rejecting SHA-1 certificates crypto/x509 will now reject certificates signed with the SHA-1 hash function. This doesn't apply to self-signed root certificates. Practical attacks against SHA-1 have been demonstrated since 2017 and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.
This can be temporarily reverted by setting the GODEBUG=x509sha1=1 environment variable. This option will be removed in a future release
Setting the GODEBUG=x509sha1=1 makes the Kafka tests pass. I think we will at least need a note about this in our release notes, and we will need to document the GODEBUG work around in case any of our users are affected by this.
More than go 1.18.x, we should target either go 1.18.6+ (and why not 1.19.5 for example or fresh 1.20.0?).
Indeed, in versions prior to 1.18.6 / 19.1 there are some CVEs reported:
Beats is currently shipped with Go 1.18.10 in 8.6 https://github.com/elastic/beats/blob/8.6/.go-version
We keep up with the Go patch releases as they are released and track the CVEs internally. Upgrading minor versions e.g. 1.18 to 1.19 is usually more delayed as a Beats is a large enough project that it can and has been affected by bugs in Go itself.
Now that Go 1.20 is released we will be prioritizing the move to Go 1.19 to ensure we continue using a version of Go that receives regular security updates. This move was a bit more delayed that it should have been but it is coming.