v0.4.8: listeners record their bind address (trial, day 1) - #6
Merged
Conversation
…ility Day 1 of the trial on a real developer's Mac. All three fixes came from watching real output; none came from six rounds of adversarial review. The main one is a capability the tool always had the data for and discarded. lsof and ss report `127.0.0.1:64991`; the collector kept `64991`. So a loopback-only listener was indistinguishable from `*:4444` — and on a dev machine java, node, claude and python bind loopback constantly, which was the dominant listener noise. A new listener bound ONLY to loopback is now YELLOW: visible, below the --notify threshold. Any non-local binding stays ORANGE, a mixed set stays ORANGE, and a bare port from a pre-0.4.8 snapshot is treated as UNKNOWN and stays ORANGE — unknown is never assumed safe. Rotation suppression works on bindings, so the v0.4.7 rapportd fix is preserved. Also: build outputs (target/build/dist/Pods/__pycache__/.venv) are pruned from the big-file scan — one Rust workspace produced +772MB across 15 dep-graph.bin/.rlib entries in a day, crowding out anything worth seeing. And "changed" software now gets shell-history attribution, not just "added": claude-code 2.1.206 -> 2.1.212 was reported with why=None while `brew upgrade claude-code` sat in the history. Upgrade note: listener values change from `4444` to `addr:4444`, so listeners appear once as removed+added. Suite 667 -> 689; mutations N1-N5 all caught. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Day 1 of a three-day trial on a real developer's Mac. All three fixes came from watching real output; none came from six rounds of adversarial review.
The tool had this data all along and threw it away
lsofandssreport the bind address. The collector kept only the port:So a loopback-only listener was reported at the same severity as one listening on every interface. On a developer machine
java,node,claudeandpythonbind loopback constantly — that was the dominant source of listener noise, and it made the category's ORANGE findings something you learn to skim past.A new listener bound only to loopback is now YELLOW — visible in the report, below the
--notifythreshold.127.0.0.1:64991,[::1]:8080*:4444,0.0.0.0:22,192.168.1.5:4444127.0.0.1:8080,*:9090(mixed)4444(pre-0.4.8 snapshot)Rotation suppression operates on bindings, so the v0.4.7
rapportdfix is preserved.Two smaller ones, same source
Build outputs pruned from the big-file scan. One Rust workspace produced +772 MB across 15
dep-graph.bin/.rlibentries in a single day, crowding out anything a person would want to see.target,build,dist,Pods,__pycache__,.venv,venvjoinnode_modules.Changed software gets its "why".
claude-code 2.1.206 → 2.1.212was reported with no attribution whilebrew upgrade claude-codesat one line up in the shell history — attribution ran only foradded.What the trial has confirmed is working
The same day's data shows correct behaviour worth noting: an edit to
~/.zshrcwas caught with an accurate diff, a newly installed Chrome extension was caught with its version and manifest hash (invisible before v0.4.6's fingerprint fix), and no finding recurred across cycles once v0.4.7 landed.Suite 667 → 689; mutations N1–N5 all caught, including "assume an unknown bare port is local", which is the unsafe direction of this change.
Upgrade note: listener values change from
4444toaddr:4444, so listeners appear once as removed+added.🤖 Generated with Claude Code