fix: bump x/net + jsonparser to clear govulncheck advisories #145
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/OpenSpec
Kind/Security
Kind/Testing
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
RFC - Request For Comments
Reviewed/Confirmed
Reviewed/Duplicate
Reviewed/Invalid
Reviewed/Won't Fix
Status/Abandoned
Status/Blocked
Status/Need More Info
hermes-attempted
hermes-needs-clarification
hermes-ready
hermes-review
hermes-wip
human-required
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
agentic-forges/forgejo-mcp!145
Loading…
Reference in a new issue
No description provided.
Delete branch "refs/pull/145/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
ci.yml run #151 flagged govulncheck advisories. Local scan (govulncheck v1.3.0) showed 7 findings, 0 of them symbol-reachable from forgejo-mcp code. Default govulncheck exits 0 on non-reachable findings, so the runner failure mode may be a stricter flag/version — this PR clears the advisories regardless so the question becomes moot.
Findings cleared
golang.org/x/net/idnav0.54.0 → v0.55.0golang.org/x/net/htmlv0.54.0 → v0.55.0golang.org/x/net/htmlv0.54.0 → v0.55.0golang.org/x/net/htmlv0.54.0 → v0.55.0golang.org/x/net/htmlv0.54.0 → v0.55.0golang.org/x/net/htmlv0.54.0 → v0.55.0github.com/buger/jsonparserv1.1.1 → v1.1.2Why a direct require for
jsonparserbuger/jsonparserarrives 4 hops deep:Without a direct
require,go mod tidykeeps the transitively-pinned v1.1.1.go get github.com/buger/jsonparser@v1.1.2promotes it to a direct require, overriding the pin. Whenwk8/go-ordered-mapeventually bumps, the direct require can be removed.Verification
make build— greengo test ./...— all packages green (incl.test/race)Test plan
Not addressed here
The underlying ambiguity — was govulncheck really the failing step in run #151? — is still unconfirmed because Codeberg's action log isn't publicly fetchable via WebFetch. If the failure resurfaces after this merge, capture the failing step log and file under
forgejo-mcp-e9i(parent investigation bead).Refs forgejo-mcp-p1p.
op1st Pipelines as Code/code-scans-wvxrp is running.
Starting Pipelinerun code-scans-wvxrp in namespace op1st-pipelines
You can monitor the execution using the op1st Pipelines as Code PipelineRun viewer or through the command line by
using the tkn CLI with the following command:
tkn pr logs -n op1st-pipelines code-scans-wvxrp -fop1st Pipelines as Code/on-pull-request- has failed.
There was an error creating the PipelineRun: on-pull-request-
cannot use the API on the provider platform to create a in_progress status:
op1st Pipelines as Code/code-scans-wvxrp has successfully validated your commit.
Task Statuses:
fetch-source
gitleaks-version
gitleaks
Auto-labeled via
codeberg-labelskill (sonnet subagent).x/net,jsonparser).Tracked locally as
forgejo-mcp-02o.