mirror of
https://github.com/hanzoai/email-verifier.git
synced 2026-10-30 15:04:29 +00:00
Jason MaandGitHub
0eee045549
govulncheck reports two vulnerabilities this package's own code reaches, both
through domainToASCII at util.go:25, which is on the path from three exported
functions:
Verify(email) → IsDisposable(syntax.Domain) → misc.go:24 ┐
CheckMX(domain) → mx.go:16 ├→ idna.ToASCII
CheckSMTP(domain, username) → smtp.go:122 ┘
GO-2026-5970 golang.org/x/text infinite loop on invalid input
GO-2026-5026 golang.org/x/net idna accepts ASCII-only Punycode labels
The first is the one that matters: the argument is whatever the caller passes
in, so an address chosen by whoever is being verified can hang the goroutine
that verifies it.
golang.org/x/net v0.29.0 -> v0.58.0
golang.org/x/text v0.18.0 -> v0.41.0
testify v1.11.1 -> v1.12.1
Not the newest of either: v0.59.0 and v0.42.0 require Go 1.26, while v0.58.0
and v0.41.0 still require 1.25, so this takes the highest that does not raise
the floor further. It also clears GO-2026-5942 in x/net/dns/dnsmessage, which
nothing here calls. govulncheck goes from two reachable, one imported and
eleven in required modules, to none.
The floor has to move: go.mod goes from 1.22 to 1.25.0, because the versions
carrying the fixes require it. That also settles what this module supports --
the three most recent Go releases, 1.25 through 1.27, with the oldest of them
as the go directive. Go 1.22 had been out of support for some time, so the
floor was overdue regardless, but it is breaking for anyone pinned below 1.25.
README says so now, next to the install instructions.
CI covers all three rather than the single version it used to name, and the
matrix comment records that the low end and the go directive move together.
The workflow splits in two. Lint has no reason to run once per Go version, and
under a matrix it would have produced three copies of every annotation, so it
is its own job on one toolchain while Test keeps the matrix. Job names change
from "Lint/Test" to "Lint" and "Test"; main's protection requires reviews but
names no status checks, so nothing was pinned to the old names.
golangci-lint had to move with the floor, which the first version of this
change got wrong -- it left the pin alone and called that a follow-up. It is a
prerequisite: v2.2.1 is built with Go 1.24 and refuses outright rather than
degrading.
can't load config: the Go language version (go1.24) used to build
golangci-lint is lower than the targeted Go version (1.25.0)
v2.13.2 is built with go1.27.0. The repo's .golangci.yml needs no changes for
it and reports the same zero issues.
.pre-commit-config.yaml pinned the same v2.2.1 and moves with it, though not
for the same reason. That check compares against the Go used to build the
binary, and the hook compiles golangci-lint from the tagged source with
whatever Go is installed rather than downloading a release, so v2.2.1 there
does run against a go-1.25 module -- checked both ways, source-built v2.2.1
passes where the released binary refuses. What leaving it behind would give
you is a local linter eleven minor versions older than the one CI runs, which
is how a change passes pre-commit and fails the Lint job. The hook definitions
are identical between the two versions, so this is only the rev; the repo's
`entry: golangci-lint run` override, which drops upstream's
--new-from-rev HEAD --fix, is left as it was.
The actions move too, all three of which GitHub had started warning about:
"actions/checkout@v4, actions/setup-go@v5, golangci/golangci-lint-action@v8
target Node.js 20 but are being forced to run on Node.js 24". checkout v4->v7,
setup-go v5->v7, golangci-lint-action v8->v9, all node24 now. Each still takes
the inputs used here -- go-version, and version plus only-new-issues -- checked
against their action.yml rather than assumed.
go-edlib, httprouter and gock are already at their latest versions.
Adding 1.26 and 1.27 brought out TestStartScheduleOK, which fails on them:
--- FAIL: TestStartScheduleOK (3.00s)
schedule_test.go:23: expected: 0x3, actual: 0x2
It slept three periods of a one-second ticker and asserted exactly three
ticks. The third lands at the instant the sleep expires, so whether it is
counted is down to scheduling -- the file already carried a tolerant
assertion, commented out, from whoever hit this before.
Rewritten to wait for three firings on a channel and then assert the count is
settled. Neither assertion comes from a clock. The second one holds by
construction rather than by timing: stop() sends on an unbuffered channel, so
it blocks until the schedule goroutine receives, and that goroutine receives
only while parked in its select -- never inside a job call. Once stop()
returns no further call is possible. The period drops to 10ms, so the test
takes about 80ms rather than three seconds.
The failure rate resists pinning down, so this is not offered as a before and
after: on this machine 30 iterations failed 2 times without -race and 0 times
with it, an earlier run without -race failed 6 of 12, and CI runs with -race
and failed on two of three versions. What can be said is that the failure is
real in both environments and that the replacement cannot have this mode.
12 lines
485 B
YAML
12 lines
485 B
YAML
repos:
|
|
- repo: 'https://github.com/golangci/golangci-lint'
|
|
# Keep in step with the version the Lint job pins in
|
|
# .github/workflows/ci.yml. This hook compiles golangci-lint from source
|
|
# with whatever Go is installed, so an older rev still runs -- what it
|
|
# gives you is a local linter behind the one CI runs, which is how a change
|
|
# passes pre-commit and fails the Lint job.
|
|
rev: v2.13.2
|
|
hooks:
|
|
- id: golangci-lint
|
|
entry: golangci-lint run
|