fix(deps): update module golang.org/x/net to v0.56.0 [security] - #579
Open
rigelbuild-renovate[bot] wants to merge 1 commit into
Open
fix(deps): update module golang.org/x/net to v0.56.0 [security]#579rigelbuild-renovate[bot] wants to merge 1 commit into
rigelbuild-renovate[bot] wants to merge 1 commit into
Conversation
rigelbuild-renovate
Bot
requested a review
from mattwilkinsonn
as a code owner
August 24, 2026 06:45
Contributor
Author
ℹ️ Artifact update noticeFile name: go/go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
|
Compass engineering docs preview: https://renovate-go-golang-org-x-net.compass-eng-docs.pages.dev Deployed from |
mattwilkinsonn
approved these changes
Aug 25, 2026
mattwilkinsonn
added a commit
that referenced
this pull request
Aug 26, 2026
…727) (#626) * feat(renovate): auto-refresh pinned Nix FOD hashes on dep bump (RIG-2727) A Renovate dependency bump moves a pinned Nix fixed-output-derivation (FOD) hash, but nothing regenerates it — so the bump PR fails CI on `hash mismatch in fixed-output derivation` and can't land without a manual hand-fix. PR #579 (`golang.org/x/net` → v0.56.0 security bump) hit exactly this: its `Gates (moon + pgtest)` job failed building `compass-guestd-go-modules.drv` because the gomod change moved the Go module set but left `guest-image/default.nix`'s pinned `vendorHash` stale. Compass pins exactly two FOD hashes outside the vendored `forks/` trees: - Go `vendorHash` (buildGoModule compass-guestd) in `guest-image/default.nix` — moved by a `go/go.mod` | `go/go.sum` bump (gomod manager). - bun `outputHash` (recursive FOD of `bun install`) in `agent-image/entrypoint.nix` — moved by a `bun.lock` bump (bun/catalog manager). Neither is a URL hash `nix store prefetch-file` can recompute (that is `refresh-toolchain-hashes.ts`'s job for the vendored-binary pins). A `vendorHash`/`outputHash` is only knowable by realising the derivation. `tools/renovate/refresh-fod-hashes.ts` self-gates per FOD on its trigger manifest, fakes the pin to force the mismatch, builds the guest-image rootfs vehicle (which realises both FODs, failing fast at the FOD before the heavy compile/pack), parses the reported `got:` SRI for that derivation, and writes it back — so the bump PR lands green. Wired at two sites to survive Renovate's winner-take-all per-branch task slot: top-level `postUpgradeTasks` (branch mode — gomod and bun/npm-first branches) and the catalog `packageRule` (update mode — catalog-first branches, where the collapsed branch config evicts the top-level branch task). One command string → one anchored `allowedCommands` entry. Guarded by `config.test.ts` (command↔allowlist coupling, both-site wiring, fileFilters coverage) and a `refresh-fod-hashes.test.ts` regression suite. Verified end-to-end against real nix: the shipped script recomputes both hashes to their exact committed values. Spec-impact: none. Refs #579. Refs RIG-2727 Co-authored-by: Matt Wilkinson <matt@rigel.build> * fix(renovate): address FOD-hash review findings (RIG-2727) Review-loop fixes on PR #626, additive over the submitted tip: - Document the verified biome/devenv-channel FOD-refresh exemption. The devenv-nixpkgs lockstep branch rewrites bun.lock + the biome catalog pin but intentionally omits the FOD refresh; biome is a root-only devDependency absent from compass-agent's filtered `bun install --filter '@compass/agent'` tree (verified: not in node_modules nor .bun), so a channel bump cannot move agent-image/entrypoint.nix's outputHash. Pinned by an explicit config.test.ts guard so a future biome-in-compass-agent change forces a revisit. - Correct the catalog-rule comment: the per-upgrade FOD refresh leg is idempotent but NOT free (it re-realises the node_modules FOD once per catalog upgrade). Kept last-write-wins; noted why a same-branch short-circuit is unsafe without relying on Renovate's grouped-update apply ordering. - Make the got:-SRI parse robust: scan from the mismatch header to the next header instead of a fixed 5-line window, so a future nix that adds context lines before `got:` can't silently wedge every FOD build. Add window-boundary + no-cross-block-bleed tests. - Write the recomputed SRI literally (function replacer) so a `$`-bearing value can never be interpreted as a replacement pattern. Add a literal-write test. Co-authored-by: Matt Wilkinson <matt@rigel.build> * fix(renovate): guard FOD_ENTRIES drvFragment attribution ambiguity (RIG-2727) Round-2 review low finding: parseGotForFragment attributes a nix mismatch block to a FOD by `drvName.includes(fragment)`. Safe for the current two fragments ("go-modules"/"node-modules", mutually disjoint), but a future FOD_ENTRIES edit adding an ambiguous fragment (e.g. a bare "modules") would silently misattribute a got: SRI and write the wrong hash. Add a module-load assertion that no drvFragment is a substring of another, so such an edit fails loud at import rather than misattributing at runtime, plus a test stating the invariant. Co-authored-by: Matt Wilkinson <matt@rigel.build> --------- Co-authored-by: Matt Wilkinson <matt@rigel.build>
rigelbuild-renovate
Bot
force-pushed
the
renovate/go-golang.org-x-net-vulnerability
branch
from
August 26, 2026 06:41
fef6ae2 to
eb29761
Compare
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
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.
This PR contains the following updates:
v0.55.0→v0.56.0Parsing an invalid SVCB or HTTPS RR can panic in golang.org/x/net/dns/dnsmessage
BIT-golang-2026-46600 / CVE-2026-46600 / GO-2026-5942
More information
Details
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Configuration
📅 Schedule: (in timezone America/New_York)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.