Repository navigation
chore: clear the nightly CVE scan findings (VEX re-key, x/net, Go 1.27.3) - #9864
Conversation
GHSA-qj98-gp63-54xj was published on 2026-10-15 with CVE-2026-102748 assigned. Trivy reports the CVE ID, so the statement keyed by the GHSA ID no longer matched and the nightly scan flagged it as CRITICAL. The fix (c32f604) is in every nightly build, but the pseudo-version sorts below 25.4.0. Key the statement by the CVE, keep the GHSA as an alias, and drop the pre-emptive wording now that the advisory is public. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…1.27.3 The nightly Trivy scan flagged five HIGH findings in the dgraph binary: - CVE-2026-78669 (HTTP/2 SETTINGS flood) in golang.org/x/net v0.58.0, reachable through the gRPC and Alpha HTTP servers. - CVE-2026-111943, CVE-2026-78667, CVE-2026-78669 and CVE-2026-97031 in the Go 1.27.0 standard library (crypto/x509, net/http, net/http2, crypto/tls). Bump x/net to v0.60.0, which pulls the sibling x/ modules forward, and add a toolchain go1.27.3 directive. The go directive stays at 1.27.0 so importers don't need a newer Go. setup-go v6 prefers the toolchain directive when reading go-version-file, so the release (cd-dgraph) and nightly CVE workflows both build with 1.27.3. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
A toolchain directive is only a preference. Builds that pin their Go version with GOTOOLCHAIN=local, such as FIPS builders, ignore it and quietly ship the 1.27.0 standard library with all four CVEs. Raising the go directive to 1.27.3 makes those builds fail with "go.mod requires go >= 1.27.3" until they upgrade, instead of shipping the vulnerable stdlib. The toolchain line would now equal the go directive, so drop it. Bump the root Dockerfile's golang:1.27.0 builder too, since it would otherwise stop building. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
go.mod has required go 1.27.3 since dgraph-io#9864, but trunk still ran the go 1.27.0 runtime with golangci-lint 2.13.1. CI auto-switches to the 1.27.3 toolchain, which writes export data version 5, and the x/tools v0.49.0 importer inside golangci-lint 2.13.1 only reads up to version 4. Package x then fails to load, so every promoted x.SafeMutex method reports as undefined, and trunk flags whichever of those land in a changed hunk: s.orc.RLock undefined (type *Oracle has no field or method RLock) golangci-lint 2.15.0 is built on x/tools v0.52.0 and reads the new export data; locally it reports no new issues on this branch under the default, integration and integration2 build tags. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
**Description** This PR bumps trunk's Go runtime to `go@1.27.3` and golangci-lint to `2.15.0`, so `trunk check` can lint the module again. #9864 moved `go.mod` to `go 1.27.3`, but trunk still pins `go@1.27.0` and golangci-lint `2.13.1`. CI switches to the 1.27.3 toolchain automatically, and 1.27.3 writes export data version 5. The `x/tools` v0.49.0 importer inside golangci-lint 2.13.1 only reads up to version 4: ``` could not import internal/cpu (... export data version 5 is greater than maximum supported version 4) ``` So package `x` fails to load, every promoted `x.SafeMutex` method reports as undefined, and trunk flags whichever of those land in a changed hunk. #9747 hit it first: ``` dgraph/cmd/zero/oracle.go:602:8 s.orc.RLock undefined (type *Oracle has no field or method RLock) golangci-lint2/typecheck ``` #9864 itself passed because it changed no Go code. Any PR that touches Go files using `SafeMutex` (or anything else in `x`) will fail the same way until this lands. golangci-lint 2.15.0 is built on `x/tools` v0.52.0 and reads the new export data. I reproduced the failure locally with 2.13.1, then ran 2.15.0 under Go 1.27.3 with the repo config: no new issues on #9747 under the default, `integration` and `integration2` build tags. **Checklist** - [x] The PR title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) syntax, leading with `fix:`, `feat:`, `chore:`, `ci:`, etc. - [x] Code compiles correctly and linting (via trunk) passes locally <!-- codesmith:footer --> --- <a href="https://app.blacksmith.sh/dgraph-io/codesmith/dgraph/pr/9868?autoLogin=true&ref=codesmith_pr_footer"><picture><source media="(prefers-color-scheme: dark)" srcset="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-dark-v3.svg"><source media="(prefers-color-scheme: light)" srcset="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-light-v3.svg"><img alt="View with [code]smith" src="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-dark-v3-3x.png" width="162" height="28"></picture></a> <a href="https://backend.blacksmith.sh/track/enable-autofix?expires=1795291376&installation_model_id=8575&pr_number=9868&ref=codesmith_pr_footer&repository=dgraph-io%2Fdgraph&return_to=https%3A%2F%2Fgithub.com%2Fdgraph-io%2Fdgraph%2Fpull%2F9868&signature=c8242b1e55f9f0f9dacaa280a2232c48647eb428de7b10ecd5bfc62d42f4cbac"><picture><source media="(prefers-color-scheme: dark)" srcset="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-light.svg"><img alt="Autofix with [code]smith" src="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark-3x.png" width="190" height="28"></picture></a> <sup>Need help on this PR? Tag <code>@codesmith-bot</code> with what you need.</sup> <!-- codesmith:autofix:disabled --> <!-- /codesmith:footer --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> <!-- coderabbit-ai-generated:v1 --> ## Summary by CodeRabbit * **Chores** * Updated the versions of the Go runtime and Go linting tools used in the project. These are internal tooling updates and do not introduce user-facing changes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
**Description**
`dgraph restore -z` (offline restore) never bumps Zero's uid or
namespace lease.
`RunOfflineRestore` ran the map phase with `if _, err :=
RunMapper(...)`, which discarded the
`mapResult` that carries `maxUid` and `maxNs`. It then returned
`LoadResult{Version: ...}` under
`// TODO: Fix this return value.`, so `MaxLeaseUid` and `MaxLeaseNsId`
were always 0. `backup/run.go`
prints `Restore max uid: 0`, and its `leaseID` helper treats 0 as
"backup taken on an empty DB" and
skips the `AssignIds` call. Only the timestamp lease is bumped.
As a result, after an offline restore of a non-empty backup into a fresh
cluster, Zero's `maxUID`
stays 0. The first new node can be assigned a uid that already belongs
to a restored node (we saw
`0x1`), and the new predicates merge into that node. Nothing reports an
error, and restored data
reads back correctly; the corruption only appears on the next write. The
online `/admin` restore
is not affected, because it bumps both leases from the same mapper
result.
With ACL enabled, the colliding uids belong to ACL nodes. In a local
v25.5.0 reproduction (a backup taken
with `--acl`, offline-restored with `-z` into a fresh cluster), Zero
reported `maxUID: 0` and the first new
nodes were assigned `0x1` to `0x4`. Those uids hold the guardians group,
groot, another user and a rule, and
each merged node then carried both the application type and its ACL type
(for example
`["Item", "dgraph.type.Group"]` on the guardians node). The same backup
restored through `/admin` assigned
new uids above the backup's maximum.
The fix keeps the mapper's `maxUid` and `maxNs` across groups and
returns them in the `LoadResult`.
A second commit changes how `dgraph restore` hands those values to Zero.
It sent them as a plain
`AssignIds` request, which leases that many *more* ids instead of
raising the lease to that value. On a
fresh Zero the two are the same. But every further restore against the
same Zero moved the lease again,
by the backup's max each time. The online restore's bump (`Bump: true`,
with "Nothing to be leased"
treated as a no-op) now lives in `worker.BumpLease`, and both restore
paths use it.
Regression test: `TestRunOfflineRestoreReportsMaxLease`
(`worker/offline_restore_test.go`) writes a
real full backup through `BackupProcessor` (uids up to `0x2711` across
namespaces 0 and 2). It checks
that `RunMapper` sees both maxima, then that `RunOfflineRestore` reports
them. Before the fix it fails:
```
Error: "0" is not greater than or equal to "10001"
Error: "0" is not greater than or equal to "2"
--- FAIL: TestRunOfflineRestoreReportsMaxLease
```
After the fix it passes, as do `go test ./worker/ -run
'Restore|Backup|Manifest'`. The existing
systest backup suites call `RunOfflineRestore` but never read the lease
fields, which is why this
went unnoticed.
`TestBumpLeaseIsIdempotent` (`worker/lease_test.go`, `integration` tag,
run with
`make test-integration TEST=TestBumpLeaseIsIdempotent`) bumps a real
Zero's uid lease, then bumps it again
to the same value and to a lower one, and checks that the lease does not
move. It passes. With
`BumpLease` temporarily changed back to the old plain lease, it fails on
the repeated bump:
```
Error: "2506" is not less than "1103"
--- FAIL: TestBumpLeaseIsIdempotent
```
Docker integration suite `systest/backup/filesystem`, run locally on the
first commit, before rebasing onto
#9864 and #9868, both chore commits (each test by name, since
`-failfast` stops the package at the
first failure):
- `TestBackupFilesystem` passes. It runs `RunOfflineRestore` over a full
backup and four
incrementals.
- `TestBackupOfOldRestore`, `TestBackupSummaryManifest` and all six
`TestListBackups*` tests pass.
- `TestRestoreOfOldBackup/backup_of_21.03` fails by timing out in
`WaitForRestore`. It fails the same
way on unmodified `main` (b9d2c9c). It uses the online restore, which
this change does not touch.
Not run locally: the other backup suites (minio, encryption, nfs,
multi-tenancy, advanced-scenarios),
and an end-to-end `dgraph restore -z` followed by a check of Zero's
`/state`. That end-to-end path
was how we first found this, on v25.5.0, where Zero reported `maxUID: 0`
after the restore.
**Checklist**
- [x] The PR title follows the
[Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) syntax,
leading
with `fix:`, `feat:`, `chore:`, `ci:`, etc.
- [x] Code compiles correctly and linting (via trunk) passes locally
- [x] Tests added for new functionality, or regression tests for bug
fixes added as applicable
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- codesmith:footer -->
---
<a
href="https://app.blacksmith.sh/dgraph-io/codesmith/dgraph/pr/9869?autoLogin=true&ref=codesmith_pr_footer"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-dark-v3.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-light-v3.svg"><img
alt="View with [code]smith"
src="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-dark-v3-3x.png"
width="162" height="28"></picture></a> <a
href="https://backend.blacksmith.sh/track/enable-autofix?expires=1795451831&installation_model_id=8575&pr_number=9869&ref=codesmith_pr_footer&repository=dgraph-io%2Fdgraph&return_to=https%3A%2F%2Fgithub.com%2Fdgraph-io%2Fdgraph%2Fpull%2F9869&signature=4e6d921a95550c19003351bd5921d7ba2eaec4d6bdf9b5e3baaa830edd463ca7"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-light.svg"><img
alt="Autofix with [code]smith"
src="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark-3x.png"
width="190" height="28"></picture></a>
<sup>Need help on this PR? Tag <code>@codesmith-bot</code> with what you
need.</sup>
<!-- codesmith:autofix:disabled -->
<!-- /codesmith:footer -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
<!-- coderabbit-ai-generated:v1 -->
## Summary by CodeRabbit
* **Bug Fixes**
* Offline restore results now include the highest UID and namespace
values found across restored groups, along with the backup’s read
timestamp.
* Restore operations now advance UID and namespace leases beyond the
highest restored values, helping ensure subsequent assignments do not
reuse IDs already present in restored data.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Description
Fixes the failing
ci-dgraph-nightly-cvesscan on main(run 39700727870). Trivy flagged 6 findings in
usr/local/bin/dgraph(1 CRITICAL, 5 HIGH); the ubuntu 24.04 base layer had none. Two parts:chore(vex): CVE-2026-102748 (CRITICAL) is GHSA-qj98-gp63-54xj, the unauthenticated Zero/removeNodeDoS.The advisory went public on 2026-10-15 with a CVE assigned, and since Trivy reports the CVE ID, our statement keyed
by the GHSA ID stopped matching. The fix (c32f604) is in every nightly build; the nightly pseudo-version
(
v25.0.0-2026...) just sorts below 25.4.0. Re-keyed the statement to the CVE with the GHSA as an alias, droppedthe pre-emptive wording, and bumped the document version to 4.
chore(deps): bumpsgolang.org/x/netv0.58.0 → v0.60.0 (CVE-2026-78669, HTTP/2 SETTINGS flood, reachablethrough the gRPC and Alpha HTTP servers) and raises the
godirective to 1.27.3 for the four stdlib CVEs:This is a
godirective bump, not atoolchainline, on purpose. Atoolchainline is only a preference: buildsthat pin their Go with
GOTOOLCHAIN=local, like FIPS builders, ignore it and quietly ship the 1.27.0 stdlib.Requiring 1.27.3 makes those builds fail with
go.mod requires go >= 1.27.3until they upgrade. The cost is thatimporters of
dgraph/v25need Go 1.27.3, which is the security release anyway. Every workflow readsgo-version-file, socd-dgraphand the nightly scan build with 1.27.3 without workflow changes, and the rootDockerfilebuilder moves togolang:1.27.3. The x/net bump also pulls crypto, mod, sync, sys, term, text andtools forward.
Validation
make dgraphbuilds and the binary reportsgo1.27.3. WithGOTOOLCHAIN=localon Go 1.27.0 the build now failswith
go.mod requires go >= 1.27.3 (running go 1.27.0; GOTOOLCHAIN=local).govulncheck ./...shows no stdlib or x/net findings. The remaining reachable hits are ingithub.com/docker/docker(no fix available), which only the test harness uses; it isn't linked into the
dgraphbinary.v25.0.0-...pseudo-version CIdoes: 8 findings without VEX, all in dgraph's own module; 0 with
--vex openvex.json(exit 0).Once this lands, a
workflow_dispatchrun ofci-dgraph-nightly-cvesshould confirm the scan is green.Checklist
Conventional Commits syntax, leading
with
fix:,feat:,chore:,ci:, etc.Need help on this PR? Tag
@codesmith-botwith what you need.Summary by CodeRabbit