larvit/fejkdata
3
0
Fork 0
Code Pull Requests 1 Actions Activity

Answer architecture round 2: 1 🔴, 3 🟡; read the report and edit the plan in two functions, propose only while no pull request is open, and test filing into the repository's own todo.md

Browse Source
This commit is contained in:
Lilleman auf Larv
2026-10-14 13:03:56 +02:00
committed by Lillem4n
parent 273dd45128
commit 2d86f4f0c0
9 changed files with 209 additions and 141 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/decisions.md
+15 -11
View File
@@ -990,17 +990,21 @@ runners, which Docker Hub's per-IP limit on anonymous pulls blocks. Leaving Dock
costs each user an edit of every `docker run` line and pinned script that names the bare
`larvit/fejkdata`.
## A known vulnerability in the Go release or the module blocks a release, called or not, and no merge
## A known vulnerability in the Go version or a required module blocks a release, even in code fejkdata never calls, and blocks no merge
2026-10-14, decided by the maintainer after Docker Hub flagged v0.1.0's image. Serves goal
1.1. `govulncheck -scan module` fails on any known vulnerability in the Go release the gate
builds with or in the module's requirements, even one fejkdata never calls: the release
binaries carry that Go release, and image scanners flag it whatever the code reaches. It
1.1. `govulncheck -scan module` fails on any known vulnerability in the Go version the gate
builds with or in a module fejkdata requires, even one fejkdata never calls: the release
binaries carry that Go version, and image scanners flag it whatever the code reaches. It
runs on every pull request and push and daily, as a job the release job needs but branch
protection does not require. A vulnerability published in Go, or an outage of vuln.go.dev,
so holds the release and leaves unrelated pull requests mergeable. Each vulnerability is
filed as a `security` item atop the next release in `todo.md`, by a pull request CI opens,
so the plan names it before anyone reads a red run. Where no Go release
fixes a vulnerability yet, govulncheck has no ignore list: the maintainer drops the job
from the release's `needs` until one does, and records why here. Valid while the binaries
are built from the gate's Go release.
protection does not require. So a vulnerability published in Go, or an outage of
vuln.go.dev, holds the release and leaves unrelated pull requests mergeable. Each
vulnerability is filed as a `security` item atop the next release in `todo.md`, by a pull
request CI opens, so the plan names it before anyone reads a red run.
`release-tooling/file_vulnerabilities.py` writes that item in `todo.md`'s shape and scores it
by `todo.md`'s formula, because CI cannot reach `rank_todo.py`; a test files one into the
repository's own `todo.md`. When the next release has no item left and waits to be cut,
`todo.md` names no version for it, so the item lands in the release after; the maintainer
moves it. Where no Go version fixes a vulnerability yet, govulncheck has no ignore list: the
maintainer drops the job from the release's `needs` until one does, and records why here.
Valid while the binaries are built from the gate's Go version.