Found in review of sneak/smallwebwaf#67. The canonical .golangci.yml enables canonicalheader (through default: all), and with golangci-lint v2.14.0 it misses findings at random: on an identical tree with a known finding (r.Header.Get("X-Real-Ip")), make lint exited 0 with no issues on 2 of 15 runs. The reviewer traced it to the linter taking the first net/http name Header it meets in an unordered map; when that is ResponseWriter.Header(), it skips the whole package without a word. So the same commit can lint red on one run and green on the next, in every Go repository that vendors this file.
Fix
First reproduce it with the pinned image (golangci/golangci-lint@sha256:ad862ba6b3798cbe0fd9fd7408d498fd74fbd2623a92406b2fd3898faf0bf98f) on a scratch module with one known finding and a ResponseWriter.Header() call in the same package, linted at least 20 times. If it reproduces, add canonicalheader to the disable list of the canonical .golangci.yml with a one-line comment saying why and that it comes back once a pinned golangci-lint release fixes it, in the style of the other entries there. If it does not reproduce, say so on this issue with what was run, and change nothing.
Not part of this issue: reporting it upstream.
Definition of done
Either canonicalheader is disabled with that comment, or this issue records that the defect did not reproduce.
The .golangci.yml sha256 is in the PR body, for repositories re-vendoring it.
make check passes.
Model: opus-5-5
Found in review of https://git.eeqj.de/sneak/smallwebwaf/pulls/67. The canonical `.golangci.yml` enables `canonicalheader` (through `default: all`), and with golangci-lint v2.14.0 it misses findings at random: on an identical tree with a known finding (`r.Header.Get("X-Real-Ip")`), `make lint` exited 0 with no issues on 2 of 15 runs. The reviewer traced it to the linter taking the first `net/http` name `Header` it meets in an unordered map; when that is `ResponseWriter.Header()`, it skips the whole package without a word. So the same commit can lint red on one run and green on the next, in every Go repository that vendors this file.
## Fix
First reproduce it with the pinned image (`golangci/golangci-lint@sha256:ad862ba6b3798cbe0fd9fd7408d498fd74fbd2623a92406b2fd3898faf0bf98f`) on a scratch module with one known finding and a `ResponseWriter.Header()` call in the same package, linted at least 20 times. If it reproduces, add `canonicalheader` to the `disable` list of the canonical `.golangci.yml` with a one-line comment saying why and that it comes back once a pinned golangci-lint release fixes it, in the style of the other entries there. If it does not reproduce, say so on this issue with what was run, and change nothing.
Not part of this issue: reporting it upstream.
## Definition of done
- Either `canonicalheader` is disabled with that comment, or this issue records that the defect did not reproduce.
- The `.golangci.yml` sha256 is in the PR body, for repositories re-vendoring it.
- `make check` passes.
Model: opus-5-5
clawbot
self-assigned this 2026-10-06 02:41:03 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found in review of sneak/smallwebwaf#67. The canonical
.golangci.ymlenablescanonicalheader(throughdefault: all), and with golangci-lint v2.14.0 it misses findings at random: on an identical tree with a known finding (r.Header.Get("X-Real-Ip")),make lintexited 0 with no issues on 2 of 15 runs. The reviewer traced it to the linter taking the firstnet/httpnameHeaderit meets in an unordered map; when that isResponseWriter.Header(), it skips the whole package without a word. So the same commit can lint red on one run and green on the next, in every Go repository that vendors this file.Fix
First reproduce it with the pinned image (
golangci/golangci-lint@sha256:ad862ba6b3798cbe0fd9fd7408d498fd74fbd2623a92406b2fd3898faf0bf98f) on a scratch module with one known finding and aResponseWriter.Header()call in the same package, linted at least 20 times. If it reproduces, addcanonicalheaderto thedisablelist of the canonical.golangci.ymlwith a one-line comment saying why and that it comes back once a pinned golangci-lint release fixes it, in the style of the other entries there. If it does not reproduce, say so on this issue with what was run, and change nothing.Not part of this issue: reporting it upstream.
Definition of done
canonicalheaderis disabled with that comment, or this issue records that the defect did not reproduce..golangci.ymlsha256 is in the PR body, for repositories re-vendoring it.make checkpasses.Model: opus-5-5
Reproduced with the pinned image:
canonicalheaderis disabled in #108.Model: opus-5-5