chore(update): bump go-github@v92.0.0 - #785
Merged
Merged
Conversation
Pass the HTTP client through WithHTTPClient and handle the error returned by NewClient. This fixes the constructor mismatch with v92 while retaining the existing transport and timeout settings. Fixes #784 Signed-off-by: Dwi Siswanto <git@dw1.io>
SeriesOfTubez
pushed a commit
to SeriesOfTubez/constellus-binaries
that referenced
this pull request
Sep 19, 2026
Review follow-ups on this PR, plus the conflict resolution from rebasing onto the verify/publish split in #5. **The gate could fail open.** govuln-gate.sh treats an empty reachable.txt as a pass, and reachable.txt is produced by a jq filter on `.finding.trace[0] .function`. If govulncheck's JSON shape shifts, the filter matches nothing, the allowlist and its expiry dates are bypassed, and the build goes green -- a state indistinguishable from a clean scan. Exit code 3 already says findings exist, so that case now cross-checks that the parse produced something and fails loudly when it did not. "No reachable findings" must be derived, never merely the absence of output. **govulncheck is pinned to v1.8.0** rather than @latest. Its JSON schema is now load-bearing for a safety decision, so an unpinned upgrade is exactly the event the check above defends against. Bumping it should be a reviewable edit, which is the same argument this repo already makes for every binary it builds. **GOTOOLCHAIN=local**, in both the workflow and both Dockerfiles. Go defaults to `auto`, so a dependency whose go directive outruns GO_VERSION is silently satisfied by downloading a newer toolchain. That makes the GO_VERSION pin decorative, and worse, lets the Docker build and the CI gate resolve different toolchains -- so the gate would verify a different standard library than the one that ships, which is precisely the class of finding that took zgrab2 red for five weeks. Now it fails loudly and raising GO_VERSION stays deliberate. Not hypothetical: projectdiscovery/utils#785, the fix for our accepted finding, raises utils to `go 1.26.0`. Adopting it without this would have silently switched toolchains. **The upstream reference was stale.** Our report was transferred by PD from cdncheck#524 to projectdiscovery/utils#784 -- not deleted, and assigned to a maintainer, who opened #785 the next day bumping go-github v30 to v92. build.env now points at the canonical issue, the in-flight fix, and the route to clearing the acceptance early: GO_PATCHES can override projectdiscovery/utils directly once it tags, so GOVULN_ALLOW gets deleted rather than extended without waiting for a cdncheck release. **Conflicts from #5:** cdncheck added to BOTH matrices (verify and publish), and the README's Published table merged with main's Artifact table. That table also claimed zgrab2 was v1.0.0; it is built from pinned commit master-e5172a7, because v1.0.0 predates the rdp module the scanner-worker needs (planning#67). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SeriesOfTubez
pushed a commit
to SeriesOfTubez/constellus-binaries
that referenced
this pull request
Sep 19, 2026
First CI run of the pinned gate failed both binaries: golang.org/x/vuln@v1.8.0 requires go >= 1.26.0 (running go 1.25.13; GOTOOLCHAIN=local) That is GOTOOLCHAIN=local doing exactly what it was added for. x/vuln v1.8.0 declares `go 1.26.0`, so installing it needs a newer toolchain than GO_VERSION pins — and the previous `@latest` under the default GOTOOLCHAIN=auto was silently downloading one to build the scanner. The guard turned an invisible toolchain switch into a visible build failure on its first run. v1.7.0 declares `go 1.25.0`, so the tool and the analysis stay on the one toolchain GO_VERSION names. The JSON the gate parses is unchanged between them. Moving to v1.8.0 means moving GO_VERSION to 1.26.x, which changes what we ship and deserves its own commit with both images rebuilt against it — not a drive-by inside a CI fix. projectdiscovery/utils#785 forces that decision soon regardless, since it raises utils to `go 1.26.0`; Go 1.26.6+ also carries the four stdlib fixes 1.25.13 carries, so that path stays clear when we take it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SeriesOfTubez
added a commit
to SeriesOfTubez/constellus-binaries
that referenced
this pull request
Sep 19, 2026
* feat(cdncheck): add cdncheck as a published binary (planning#6)
Tier 0's CDN/WAF/cloud half of epic#178, built the same way as zgrab2: pinned
source tag, govulncheck reachability gate, scratch image, SBOM + SLSA
provenance. Upstream is MIT, actively maintained, and v1.3.1 is three days old.
Two things about this tool that the issue's framing does not capture, both
recorded in build.env so they aren't rediscovered later:
**The dataset is compiled in, not fetched at runtime.** cdncheck `//go:embed`s
a ~2.4 MB `sources_data.json` of CIDR/ASN ranges at build time. "Auto-updating"
means "updates when you rebuild", not "refreshes itself in production" - so
this repo *is* the update mechanism, and a deployment pinned to an old digest
serves old ranges. Treat a stale cdncheck pin the way you'd treat a stale
dataset.
**It phones home on every run unless stopped.** Without `-duc`, cdncheck calls
ProjectDiscovery's version endpoint on every invocation. Verified with
`--network none` that the check fails soft and classification still works, but
every consumer must pass `-duc` regardless: an outbound call per scan is
latency we don't need, and a security product should not phone home by default.
Kept on `scratch` despite upstream's own image using alpine + ca-certificates +
bind-tools, because our use - IP to {is_cdn, is_waf, is_cloud, provider} from
the embedded dataset - needs no DNS and no TLS. Shipping without a CA bundle
also means the phone-home fails closed if a consumer forgets `-duc`. The
trade-off is recorded: cdncheck's CNAME detection needs DNS and its ipinfo path
needs TLS, so either would require a different base - a deliberate change.
Verified by building the image locally and classifying known IPs:
151.101.1.1 -> cdn/fastly, 1.1.1.1 -> waf/cloudflare, 104.16.132.229 ->
waf/cloudflare, 13.107.42.14 -> cloud/azure, all with `--network none`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(cdncheck): Go 1.25.13 + goldmark patch clears 6 of 7 reachable vulns
Ran the repo's govulncheck gate against cdncheck v1.3.1 locally, since
build.yml only triggers on push to main and so would not have gated this PR.
It found 7 reachable vulnerabilities:
GO-2026-6218 net/url -> fixed in go1.25.13
GO-2026-6090 crypto/tls -> fixed in go1.25.13
GO-2026-6088 encoding/xml -> fixed in go1.25.13
GO-2026-5972 encoding/asn1 -> fixed in go1.25.13
GO-2026-5026 net/http (idna) -> fixed in go1.25.13
GO-2026-5320 yuin/goldmark XSS -> fixed in goldmark v1.7.17
GO-2026-5932 x/crypto/openpgp -> NO FIX AVAILABLE
Bumping GO_VERSION to 1.25.13 and pinning goldmark via GO_PATCHES clears six.
Verified: re-running the gate now reports exactly one remaining finding.
The survivor is notable. GO-2026-5932 is the "x/crypto/openpgp is unmaintained
and unsafe by design" advisory, it has no fixed version, and every trace
reaches it through `update.init` — cdncheck's self-update machinery. That is
the same feature that phones home on every run and that we already disable
with `-duc`. So the one unfixable finding and the one behaviour we don't want
are the same code path, linked in at init and not removable by flag.
Left unresolved deliberately: accepting it needs a suppression mechanism this
repo does not have, and adding one changes the gate for zgrab2 too. That is a
posture decision, not a mechanical one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(cdncheck): correct a wrong security claim about the scratch base
The build.env rationale claimed that shipping without a CA bundle makes
cdncheck's phone-home "fail closed" if a consumer forgets `-duc`. That is
wrong. projectdiscovery/utils/update constructs its version-check client with
`InsecureSkipVerify: true` (update.go, init()), so the call validates no
certificate and needs no root store - it works fine from scratch.
Verified both ways: with a network and no `-duc`, the image logs "Current
cdncheck version v1.3.1 (latest)"; with `--network none` that line is absent.
`-duc` is the only thing that actually stops the outbound call, so the doc now
says so instead of implying a defence that isn't there.
Also recorded what that flag means for the call itself: encrypted against a
passive observer, but an on-path attacker can impersonate api.pdtm.sh with any
certificate, the realistic abuse being version-check suppression. It does not
extend to the binary download, which uses a separate client and validates
release checksums.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(ci): time-boxed govulncheck allowlist, and accept GO-2026-5932 for 30 days
The gate had no way to express "reviewed, accepted, no fix exists", so a
finding like GO-2026-5932 could only be fixed or silently tolerated by not
running the gate. This adds the missing third option without weakening the
default.
The gate stays deny-by-default. A reachable finding fails the build unless the
binary's build.env names it in GOVULN_ALLOW with a review date still in the
future:
GOVULN_ALLOW=GO-2026-5932:2026-10-16
Properties that make this an acceptance rather than a mute:
- The date is a deadline. Once it passes the build fails until someone
re-reads the finding; extending it is a commit, not an edit.
- Only the named ID is accepted. A new reachable finding fails even while an
existing acceptance is live.
- An entry that is no longer reachable warns and asks to be deleted, rather
than failing - upstream fixing something must not break the build.
- A binary with no GOVULN_ALLOW is gated strictly, which stays the normal
case. zgrab2 is unchanged.
The gate now reads govulncheck's JSON and filters to symbol-level findings -
traces naming a function the built command actually calls. That filter is what
keeps it actionable: at cdncheck v1.3.1 it yields 1 reachable finding rather
than the 3 that appear at any level.
cdncheck's GO-2026-5932 is accepted until 2026-10-16. Grounds are recorded in
its build.env: no fixed version exists (the package is deprecated, not
defective), every trace is init-time registration inside the self-update path,
and `-duc` means the updater never fetches or verifies a release. The upstream
fix is a go-github bump in projectdiscovery/utils, filed as
https://github.com/projectdiscovery/cdncheck/issues/524 - which is the question
to answer at expiry.
Verified against the real toolchain: the gate passes today and fails on
2026-10-17. Script logic covered for allowed/expired/unlisted/new-finding/
stale-entry/boundary/malformed-entry cases.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(ci): pin govulncheck, fail closed on a broken parse, pin GOTOOLCHAIN
Review follow-ups on this PR, plus the conflict resolution from rebasing onto
the verify/publish split in #5.
**The gate could fail open.** govuln-gate.sh treats an empty reachable.txt as a
pass, and reachable.txt is produced by a jq filter on `.finding.trace[0]
.function`. If govulncheck's JSON shape shifts, the filter matches nothing, the
allowlist and its expiry dates are bypassed, and the build goes green -- a state
indistinguishable from a clean scan. Exit code 3 already says findings exist, so
that case now cross-checks that the parse produced something and fails loudly
when it did not. "No reachable findings" must be derived, never merely the
absence of output.
**govulncheck is pinned to v1.8.0** rather than @latest. Its JSON schema is now
load-bearing for a safety decision, so an unpinned upgrade is exactly the event
the check above defends against. Bumping it should be a reviewable edit, which is
the same argument this repo already makes for every binary it builds.
**GOTOOLCHAIN=local**, in both the workflow and both Dockerfiles. Go defaults to
`auto`, so a dependency whose go directive outruns GO_VERSION is silently
satisfied by downloading a newer toolchain. That makes the GO_VERSION pin
decorative, and worse, lets the Docker build and the CI gate resolve different
toolchains -- so the gate would verify a different standard library than the one
that ships, which is precisely the class of finding that took zgrab2 red for five
weeks. Now it fails loudly and raising GO_VERSION stays deliberate.
Not hypothetical: projectdiscovery/utils#785, the fix for our accepted finding,
raises utils to `go 1.26.0`. Adopting it without this would have silently
switched toolchains.
**The upstream reference was stale.** Our report was transferred by PD from
cdncheck#524 to projectdiscovery/utils#784 -- not deleted, and assigned to a
maintainer, who opened #785 the next day bumping go-github v30 to v92. build.env
now points at the canonical issue, the in-flight fix, and the route to clearing
the acceptance early: GO_PATCHES can override projectdiscovery/utils directly
once it tags, so GOVULN_ALLOW gets deleted rather than extended without waiting
for a cdncheck release.
**Conflicts from #5:** cdncheck added to BOTH matrices (verify and publish), and
the README's Published table merged with main's Artifact table. That table also
claimed zgrab2 was v1.0.0; it is built from pinned commit master-e5172a7, because
v1.0.0 predates the rdp module the scanner-worker needs (planning#67).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(ci): pin govulncheck v1.7.0, not v1.8.0 — v1.8.0 requires Go 1.26
First CI run of the pinned gate failed both binaries:
golang.org/x/vuln@v1.8.0 requires go >= 1.26.0
(running go 1.25.13; GOTOOLCHAIN=local)
That is GOTOOLCHAIN=local doing exactly what it was added for. x/vuln v1.8.0
declares `go 1.26.0`, so installing it needs a newer toolchain than GO_VERSION
pins — and the previous `@latest` under the default GOTOOLCHAIN=auto was
silently downloading one to build the scanner. The guard turned an invisible
toolchain switch into a visible build failure on its first run.
v1.7.0 declares `go 1.25.0`, so the tool and the analysis stay on the one
toolchain GO_VERSION names. The JSON the gate parses is unchanged between them.
Moving to v1.8.0 means moving GO_VERSION to 1.26.x, which changes what we ship
and deserves its own commit with both images rebuilt against it — not a drive-by
inside a CI fix. projectdiscovery/utils#785 forces that decision soon regardless,
since it raises utils to `go 1.26.0`; Go 1.26.6+ also carries the four stdlib
fixes 1.25.13 carries, so that path stays clear when we take it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(ci): the fail-closed check never ran — json mode does not exit 3
Investigated because the 'parsed N finding(s)' line never appeared in the
green run. It was not a log artifact: the branch was dead.
Evidence, from x/vuln v1.7.0 source:
run.go:81 the command's exit status is Flush(handler)
run.go:160-164 Flush calls h.Flush() ONLY if the handler implements it,
otherwise returns nil
jsonhandler.go jsonHandler implements Config/Progress/SBOM/OSV/Finding
and no Flush at all
text.go:84 errVulnerabilitiesFound (code 3) is returned only by the
TEXT handler's Flush
So `govulncheck -format json` exits 0 even with findings. The previous check
was guarded on `rc -eq 3` after the json run, which is never true — it never
executed once. The pre-existing comment it inherited ('Exit 3 means
vulnerabilities found') is also wrong for the json invocation it annotates,
which is how the mistake was inherited rather than noticed.
The fix uses the text invocation that already runs for human-readable logging.
Text mode DOES exit 3, and precisely when findings match the scan level
(symbol, by default) — the same question the jq filter asks. So the two
renderings of one scan become a cross-check: if text reports symbol-level
findings and the JSON parse produced none, the filter or the schema is broken
and the gate fails closed. Its exit code is now captured instead of discarded
with `|| true`.
json_rc is kept, but only as a tool-failure signal, and is now commented as
such so it is not misread as a verdict again.
Note the irony, and the lesson: a check written to stop the gate failing
silently was itself silently not running. Only the absence of an expected log
line gave it away.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: SeriesOfTubez <8f9txk9x5v@privaterelay.appleid.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
SeriesOfTubez
added a commit
to SeriesOfTubez/constellus-binaries
that referenced
this pull request
Sep 19, 2026
…85) (#6) Both binaries moved off the 1.25 line. Two things we depend on now declare `go 1.26.0` — x/vuln v1.8.0, the govulncheck the gate installs, and projectdiscovery/utils#785, the upstream fix for the accepted GO-2026-5932 finding in cdncheck. Under GOTOOLCHAIN=local (#5) a 1.25 toolchain cannot build either, so this is forced rather than housekeeping: the alternative is dropping the toolchain guard, which only hides which stdlib we ship. No regression on the four reachable stdlib findings that took the weekly scan red for five weeks: the Go vulnerability database records GO-2026-6218, GO-2026-6090, GO-2026-6089 and GO-2026-5972 as fixed in both 1.25.13 and 1.26.6, and this pins 1.26.8. Deliberately landed before projectdiscovery/utils tags a release carrying #785 (still open; latest tag v0.11.4 predates it). Bundled, a failure would have two candidate causes — "does 1.26 build our binaries" and "does the upstream fix clear GO-2026-5932" stay separate variables. Re-verified against x/vuln v1.8.0 before moving the pin: jsonHandler still implements no Flush, so `-format json` still exits 0 with findings and the text/JSON cross-check remains the gate's real guard; `finding.trace[].function` is unchanged, so the jq filter still matches. - binaries/{zgrab2,cdncheck}/build.env: GO_VERSION 1.25.13 -> 1.26.8 - .github/workflows/build.yml: govulncheck v1.7.0 -> v1.8.0, and the comment explaining why v1.8.0 could NOT be used is deleted rather than left to mislead - binaries/*/Dockerfile: the ARG GO_VERSION fallback tracks the pin's minor, so a bare local `docker build` does not fail obscurely under GOTOOLCHAIN=local Consumer pins are deliberately NOT moved in this pass: zgrab2's source REF is unchanged, so only the digest shifts, and scanner-worker's existing image is built with 1.25.13, which carries all four stdlib fixes. Follow-up filed. Co-authored-by: SeriesOfTubez <8f9txk9x5v@privaterelay.appleid.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Mzack9999
approved these changes
Sep 21, 2026
Mzack9999
deleted the
dwisiswant0/chore/update/bump-go-github-v92-0-0
branch
September 21, 2026 20:26
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pass the HTTP client through WithHTTPClient and handle the error
returned by NewClient. This fixes the constructor mismatch with v92
while retaining the existing transport and timeout settings.
Fixes #784