CveDeck 0.8.12

The git hooks are this project's primary guard against publishing a secret. The
last three releases were all about checks positioned where they could not see
what they were written to catch, and nobody had turned that question on the
hooks themselves. It had two answers.

No database migration, no application code changes.

A secret added and then deleted was never caught

The pre-push content scan compared two trees — git diff BASE LOCAL_SHA. A file
added in one commit and removed in the next nets out to nothing, so it never
appeared in the diff and was never examined. That is exactly the case the check
exists for.

Three documents described the correct behaviour while the code did not have it:
the comment three lines above the scan ("the first catches a secret added then
deleted"), AGENTS.md §6 ("history included"), and the methodology document
("a secret removed in a later commit still leaks"). A specification with no test
behind it, since 0.6.0.

It scans per-commit patches across the pushed range now, so a secret is caught
by having been committed rather than by surviving to the tip. Verified both ways
round in a scratch repository — a private key block and a forbidden filename,
each added and then deleted before pushing, pass the old hook and are refused by
the new one, on a first push as well as an incremental one.

If you use these hooks, this is the release to take.

The hooks no longer publish one machine's release workflow

More than half of pre-push implemented something specific to how this
repository is published: a private staging repository, a clean room that
receives only snapshots, the config that tells them apart, the release identity,
version consistency across three files, and a spec-citation gate. None of it
does anything in anyone else's clone.

What stays published is the half that is useful in any clone — credential,
filename and content scanning, on commit and on push. The rest moved into an
untracked local overlay that the tracked hooks source when it exists and are
complete without. That is the same arrangement the local pattern list has always
used, for the same reason: a tracked file naming the things that must never be
published would publish them.

Nothing was leaked by the old arrangement. It was simply a public repository
carrying a description of how one maintainer's disk is arranged, for ten
releases, because nobody had read it closely enough to ask.

Contributing no longer promises a gate you don't get

CONTRIBUTING.md said the hooks "refuse to push a branch whose tests are red or
whose version strings disagree". Both checks only ever ran when pushing to this
project's own remote, so a clone had neither.

It now says what the hooks do, and points at CI — which runs both suites and the
image build on every pull request, so the feedback is not lost, it just comes
from the right place. A hook that refuses to back up work in progress is a hook
people switch off.

Upgrading

Nothing to do for a running instance. If you have the hooks enabled, pull and
they are already in effect:

git config core.hooksPath .githooks

docker pull ghcr.io/reprodev/cvedeck:0.8.12

Full changelog: https://github.com/reprodev/cvedeck/blob/main/CHANGELOG.md