Skip to content

v0.30.2 — the quarantine nobody enforced, and a Monday that proves nothing

Choose a tag to compare

@lucascouts lucascouts released this 12 Sep 00:51
· 569 commits to main since this release
fc796f3

Highlights

The two dependencies nobody automates turned out to be the two whose release quarantine nothing enforces. This repo holds new releases for 7 days before taking them — the window in which most hijacked or yanked packages are caught. That hold is a Dependabot feature, so it covers only what Dependabot still handles. charmbracelet/x/exp/teatest and .../golden sit in the ignore list, because upstream publishes no semver tag and the resolver walks up to charmbracelet/x v0.1.0 and answers dependency_file_not_resolvable. The exclusion was written to silence that error; it also removed a security control, and the two facts live in the same file but were decided at different times, so nothing connected them.

The bump in this release was taken inside that quarantine, deliberately. The v0.0.0-20260906004030-3986e9119cf9 snapshot was published 2026-09-06T00:40:30Z and would have aged out 2026-09-13T00:40:30Z; it was taken on 2026-09-11, roughly 25 hours early, as an explicit override. The trap worth naming is that the date inside a pseudo-version reads older than the quarantine clock actually is — 20260906 looked like "five days ago" while the module was still held. Read the real time with go list -m -json <module>@<version> | jq -r .Time.

The chain itself carries no advisory. govulncheck is clean under the pinned go1.26.8 and not merely under a newer local Go — two different questions, because govulncheck judges the stdlib of whichever toolchain runs it, and this module now pins one. osv-scanner 2.5.1, gitleaks over 431 commits and zizmor are clean too; go mod verify passes and go mod tidy -diff is empty. Every GitHub Action remains pinned by commit SHA.

The Monday of 2026-09-14 cannot test the golang-x fix shipped in 0.30.1, and its silence is not a relapse. That fix predicts a group PR on the next weekly run. But the candidate x/ releases were published 2026-09-08, so the cooldown clears them only on 09-15 — after that Monday — and no intermediate version exists to fall back to, since each pinned version is the immediately preceding release. A cascadia PR may appear on 09-14, but cascadia is not golang.org/x/*: it proves Dependabot is running, not that the group is fixed. The first run that can confirm or refute the diagnosis is 2026-09-21.

Security

  • charmbracelet/x/exp/teatest and .../golden to their 2026-09-06 snapshot, neither carrying an advisory. Test-only: teatest drives the TUI test, golden arrives through it, neither is linked into the binary.
  • The quarantine gap is now recorded rather than merely present. Anything in Dependabot's ignore list is outside the cooldown by construction; bumping one by hand means checking the publish time yourself.
  • The remaining updates are left for Dependabot, which can see them again: andybalholm/cascadia v1.3.5 (cleared 2026-09-11), the 2026-09-08 x/ releases (09-15), mattn/go-runewidth v0.0.30 and go.mongodb.org/mongo-driver v1.17.10 (09-17).

Notes

Nothing ships. Both modules are test-only, so a consumer building this tag gets a program byte-identical to 0.30.1 — no behaviour, no configuration and no CLI surface moves. What the release records is a decision, not a change. Neither golden file needed regenerating either: TestModelGoldenFrame.golden and TestFullscreenSectionsGoldenFrame.golden are byte-identical after the bump, which makes the standing note to regenerate them a check rather than a certainty.

Full changelog: v0.30.1...v0.30.2