Bump Go to 1.23.2

[tsaarni]

This pull request includes following changes

• Updates Go major version from 1.22 to 1.23
  • See release notes: https://go.dev/doc/devel/release#go1.23.0
• Updates golangci-lint to v1.61.0
  • v1.60.1 added Go 1.23 support

Details:

The PR also includes following lint fixes:

Remove tools from build tags when running lint to avoid error

tools.go:7:2: import "github.com/ahmetb/gen-crd-api-reference-docs" is a program, not an importable package (typecheck)
        _ "github.com/ahmetb/gen-crd-api-reference-docs"

TODO:

• [ ] more linter fixes needed,see errors here https://github.com/projectcontour/contour/actions/runs/11416714889/job/31768235538?pr=6718

[tsaarni]

Marking as draft for now. There are gosec "G115: integer overflow conversion" errors, as well as some other lint errors that should be easier to fix.

[tsaarni]

I've fixed the simpler issues, but the remaining errors are gosec G115 integer overflow warnings. See details here.

In some respect, the errors seem valid and could be viewed as bugs. Some come from inconsistencies between CRD API types and Envoy API types. Changing the API types now could break backward compatibility. While it could be theoretically possible to add bounds checks and consider how to propagate errors to handle these edge cases, I’m unsure if it is practical.

There is also at least one interesting case where fixing the issue would require avoiding "range", since range index is int:

for index  := range values {
    // then process int index in uint32 context
    // will cause error: G115: integer overflow conversion int -> uint32
}

Gosec seems only accept this if adding check for both index > math.MaxUint32 and index < 0 on every iteration, even though I don't think range could generate negative index.

I have some doubts there are meaningful ways to escalate thee errors so one option is to keep the G115 on, but disable it for each remaining error with //nolint:gosec // disable G115.

What do you think?

[izturn]

in our product, we use the same way:

I have some doubts there are meaningful ways to escalate thee errors so one option is to keep the G115 on, but disable it for each remaining error with //nolint:gosec // disable G115.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 84.44444% with 7 lines in your changes missing coverage. Please review.

Project coverage is 81.03%. Comparing base (0be3efa) to head (dbc69de). Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/annotation/annotations.go	0.00%	2 Missing and 1 partial :warning:
internal/featuretests/v3/featuretests.go	0.00%	2 Missing :warning:
cmd/contour/contour.go	0.00%	1 Missing :warning:
internal/dag/gatewayapi_processor.go	87.50%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6718      +/-   ##
==========================================
- Coverage   81.04%   81.03%   -0.02%     
==========================================
  Files         133      133              
  Lines       20001    20006       +5     
==========================================
+ Hits        16210    16212       +2     
- Misses       3498     3500       +2     
- Partials      293      294       +1     

Files with missing lines	Coverage Δ
internal/dag/dag.go	98.78% <ø> (ø)
internal/dag/httpproxy_processor.go	90.97% <100.00%> (ø)
internal/dag/policy.go	95.68% <100.00%> (+<0.01%)	:arrow_up:
internal/envoy/v3/endpoint.go	100.00% <100.00%> (ø)
internal/envoy/v3/listener.go	98.49% <100.00%> (+<0.01%)	:arrow_up:
internal/envoy/v3/ratelimit.go	100.00% <100.00%> (ø)
internal/envoy/v3/route.go	80.67% <100.00%> (ø)
internal/featuretests/v3/envoy.go	99.13% <100.00%> (ø)
internal/gatewayapi/helpers.go	88.02% <100.00%> (ø)
internal/provisioner/model/model.go	100.00% <100.00%> (ø)
... and 9 more

[tsaarni]

Thanks @izturn. I took this approach, except for couple of places, where I could fix the errors with small effort.