Mark the rule blocks the taboo guard is meant to deny - #11
Merged
Merged
Conversation
Four rule files held command blocks the guard denies, and three never said so: deployment.md told heinzel to install a deploy key it may not write, while cloud-image.md and partition-staging.md ran guarded commands without the override os-replacement.md documents. The key install now goes to the user, since the guard cannot tell an appended key from a replaced one and a session-wide override is too much for one step. Each such fence now says operator or guard-off, and the test matrix runs every other block in skills/ and rules/ through the guard, so a per-block marker replaces a blanket exemption. An AI agent wrote this text in my name. I know that is problematic.
Owner
Author
|
@oliverandrich I merged this without waiting for your review, so it goes out with the next release. I'd still be glad if you took a look when you have time, above all at the deploy-key handoff in An AI agent wrote this text in my name. I know that is problematic. |
wintermeyer
added a commit
that referenced
this pull request
Sep 17, 2026
Three changes since 2.20.1, all around the taboo guard: it now catches writes into SSH keys, sshd_config and disks by the common tools (#12), rule files mark the blocks it is meant to deny (#11), and the key fingerprint probe runs in a call of its own (#10). A minor release because the guard now denies commands it used to let through; #10 and #11 close gaps Oliver Andrich found in #8. Release notes in CHANGELOG.md; the reasoning per change is in the preceding commits. An AI agent wrote this text in my name. I know that is problematic.
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.
Some rule files contain command blocks that the taboo guard denies:
deployment.mdtold heinzel to install the deploy key itself. The guard cannot tell an appended key from a replaced one, so the block now goes to the user, and heinzel checks the result read-only.cloud-image.mdandpartition-staging.mdrun guarded commands by design but never mentioned the override. They now point to the relaunch step inos-replacement.md.Each block the guard is meant to deny now says so on its fence:
operatormeans the user runs it,guard-offmeans it runs only after the relaunch. The test matrix runs every other block inskills/andrules/through the guard. Any file with aguard-offblock must nameHEINZEL_GUARD_DISABLE.Follow-ups 1 and 3 from #8, plus
partition-staging.md, which had the same gap. cc @oliverandrich, could you double-check this, please? The deploy-key handoff is the part I'm least sure about.An AI agent wrote this text in my name. I know that is problematic.