chore(deps): bump x/net to v0.57.0, raise Go floor to 1.25.12, add govulncheck CI#105
Merged
Conversation
…proval A Dockerfile.odek in the working directory was built automatically with no approval gate, while the analogous sandbox_image/sandbox_env project-config knobs correctly require explicit operator approval. docker build executes the repo-controlled Dockerfile's RUN instructions outside the sandbox threat model (default capabilities, entire working directory readable as build context), so merely running odek inside a malicious repository - including odek serve, which sandboxes by default - granted host-adjacent code execution and workspace exfiltration. Changes: - approveProjectSandbox now also requires approval for an implicit Dockerfile.odek build (sandbox active, no explicit image, file present). The approval is keyed on the Dockerfile content hash, so editing the file invalidates a prior "trust this project" approval. The prompt warns that building runs repo-controlled code with the whole working directory as build context. - setupSandbox enforces the approval non-interactively at build time (env bypass, persisted trust, or in-process session approval), closing the gap where a Dockerfile appears or changes after startup - e.g. a serve-mode sandbox created per WebSocket connection, or a session continuation that re-enables the sandbox. - continueCmd now calls approveProjectSandbox like every other command; previously odek continue applied project sandbox overrides without any approval at all. - docker build runs with --network=none by default so RUN steps cannot fetch attacker payloads or exfiltrate build-context data over the network; ODEK_SANDBOX_BUILD_NETWORK=1 (operator-only) opts back in for legitimate networked builds such as RUN apk add. Regression tests cover the requirement detection, non-TTY fail-closed behavior, env bypass, once-vs-trust semantics, content-change invalidation at both gates, build-time enforcement, and the --network=none default. Docs updated: SANDBOXING.md, SECURITY.md (new section 18b), CONFIG.md, AGENTS.md.
…vulncheck CI Addresses two dependency-floor findings: 5. golang.org/x/net v0.54.0 carried ~7 published advisories (fixed in v0.55.0/v0.56.0). None were reachable through odek's call graph, but the constraint permitted the vulnerable version. Bumped to v0.57.0 (with x/term v0.45.0 and x/sys v0.47.0 as required companions) and added a govulncheck job to CI so future advisories fail the build. 6. go.mod declared go 1.25.0; scanning with early 1.25.x toolchains traces 22 reachable stdlib CVEs (crypto/tls, crypto/x509, net/http, net/url, net, os, encoding/pem, encoding/asn1), fixed across Go 1.25.2-1.25.12. Raised the go directive to 1.25.12 (verified as the latest 1.25.x patch via go.dev/dl) and stated the minimum build toolchain in the README, docs/DEVELOPMENT.md, and the test/release workflows. Verified: govulncheck reports zero reachable module vulnerabilities after the bump; the single remaining local stdlib report (GO-2026-5856) is fixed in exactly 1.25.12 per the vuln DB and only appears because the local scanning toolchain (go1.26.4) is one patch behind. Full test suite, vet, and golangci-lint pass with the bumped dependencies.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
odek | dbaca64 | Commit Preview URL Branch Preview URL |
Jul 26 2026, 09:00 AM |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Comment on lines
+49
to
+62
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
|
|
||
| - uses: actions/setup-go@v5 | ||
| with: | ||
| # Latest stable toolchain: stdlib advisories are assessed against | ||
| # the newest patch release, and module advisories (e.g. x/net) are | ||
| # toolchain-independent. The go.mod floor (go 1.25.12) pins the | ||
| # minimum toolchain for downstream builders. | ||
| go-version: "stable" | ||
|
|
||
| - name: govulncheck | ||
| run: go run golang.org/x/vuln/cmd/govulncheck@latest ./... |
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.
Summary
Addresses the two dependency/toolchain-floor findings (both verified before changing):
Changes
go.mod/go.sum:golang.org/x/netv0.54.0 → v0.57.0 (≥ v0.56.0 per the report; v0.57.0 is the latest).golang.org/x/termv0.43.0 → v0.45.0 andgolang.org/x/sysv0.44.0 → v0.47.0 came along as required companions.godirective:1.25.0→1.25.12— confirmed viago.dev/dlthat 1.25.12 is the latest 1.25.x patch.test.yml): newvulnjob runsgovulncheck ./...on every push/PR with the latest stable toolchain, so future advisories fail the build. Module advisories (the x/net class) are toolchain-independent; stdlib advisories are assessed against the newest patch release, matching the go.mod floor.README.md(build requirements note on the install snippet),docs/DEVELOPMENT.md(prerequisites), and comments on thesetup-gosteps of bothtest.ymlandrelease.yml.Verification
govulncheck ./...after the bump: zero reachable module vulnerabilities (the ~7 x/net advisories are gone). The single remaining local report,GO-2026-5856(crypto/tls ECH privacy leak), is fixed in exactly 1.25.12 per vuln.go.dev — it only appears locally because the scanning toolchain here (go1.26.4) is one patch behind on the 1.26 line; CI on latest 1.25.x / stable will be clean.go test ./... -count=1✅ (28 packages),go vet ./...✅,golangci-lint run ./...→ 0 issues ✅