Skip to content

Raise the go directive floor to clear stale indirect dependencies #38

Description

@norman-abramovitz

The go 1.18 directive in go.mod now blocks dependency maintenance, and the
cost is visible in the OpenSSF Scorecard: the Vulnerabilities check scores
0 — "13 existing vulnerabilities detected".

Why the floor is the blocker

The vulnerabilities are in the stale indirect modules:

Module Pinned Latest
golang.org/x/net v0.35.0 (2025-02-10) v0.57.0
golang.org/x/text v0.22.0 (2025-02-04) v0.40.0

They cannot be upgraded where they are:

Version Requires
x/net v0.57.0 go 1.25.0
x/net v0.38.0 (oldest current line) go 1.23.0
x/text v0.40.0 go 1.25.0

Every candidate needs a directive above 1.18, so no amount of dependency
bumping fixes this without raising the floor first.

Worth noting make audit stays green today: govulncheck does reachability
analysis and these are unreachable from this package's code — they arrive
indirectly and test-only via gomega. Scorecard's check is presence-based, not
reachability-based. So this is a hygiene and consumer-perception problem rather
than an exploitable one here, but consumers running presence-based scanners
inherit the noise.

Scope

  • Raise the go directive (1.25 or 1.26 — decide which)
  • Upgrade golang.org/x/net and golang.org/x/text
  • Update the README "Requirements" line and the build-floor CI job's
    go-version
  • Re-enable copyloopvar and intrange in .golangci.yml — both are
    currently disabled by golangci-lint itself with
    "this linter is disabled because the Go version (1.18) of your project is
    lower than Go 1.22", and both start applying once the floor moves
  • Add a Dependabot ignore rule for gomega. The pinned-dependency guard is
    only a comment today, so Dependabot will keep re-proposing a bump that has
    been deliberately declined

Compatibility

This is the first non-additive change in a while: v1.20.0, v1.21.0 and v1.22.0
were each verified purely additive with gorelease. Raising the floor drops
support for consumers on older toolchains, so it wants its own release and a
clear note in the release body.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions