Every existing test asserted the history scan reports nothing — on this
repository, which has never committed a credential. That is the wrong
direction to test alone: a detector exercised only against clean input
is indistinguishable from a function that returns an empty vector, and
this one has already shipped four false-negative-shaped bugs today.
The new test builds a repository from scratch by writing zlib-compressed
git objects directly — no subprocess, for the same reason the scanner
uses none — commits a key, and leaves no working-tree copy at all. Only
the history has it, which is the situation the whole module exists for.
It asserts the scan finds it, names the file, says revoke, and does not
carry the credential's value into the finding. The fixture key is
assembled at runtime so this source file does not itself contain a
credential-shaped string, which is the trap that made the detector
report its own definitions earlier today.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
**The action.** `hound hygiene` and `hound supply-chain` only ever saw
repositories somebody had already cloned onto a machine with Hound
installed. action/ runs them on every push and pull request: it
installs the published .deb, verifies it against the same signed
checksum the desktop agent uses, and annotates findings on the lines of
the files they concern so a reviewer sees them in the diff rather than
in a log nobody opens.
report.py will not print a credential it found — GitHub masks only
values registered as secrets, so anything else in an annotation is
readable by everyone who can see the run and stays in the API
afterwards. And it will not report a partial scan as clean: a history
walk that hits its limit says so, because "no findings" and "no
findings in the part we looked at" mean different things to somebody
deciding whether to merge.
**The background.** A radial gradient was set on `html, body` — both,
each 100% tall — so it painted twice and the seam between the two
layers appeared as a band across the middle of the page when scrolled.
It was also a hardcoded near-black the light theme had no way to
override. Three more like it: the active tab, button hover, and the log
panel. The ground is a token now, and every colour in the stylesheet
comes from one, so no rule can put one theme's text on the other's
background.
**The palette.** The light theme now uses houndav.com's values exactly
— #5A58C8 buttons, #147A3D, #9A6100, #C22222 — so the app and the site
are recognisably the same product rather than two guesses at it.
Then measured rather than assumed, and found two failures Joe had not
mentioned: "faint" text was 2.90:1 in dark and 3.37:1 in light, and the
dark button hover was 4.41:1. All three now clear 4.5:1, and all eight
text pairs pass WCAG AA in both themes.
**And four more places still naming ClamAV**, which has not been the
engine for a long time: the auto-update caption said the daemon runs
freshclam, the update log said the same, an error suggested `apt
install clamav`, and a permissions hint pointed at /var/lib/clamav. The
engine swap replaced the code and left the copy describing software
this product no longer runs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
