Development record
abcd guard tokenizer has no backtick command-substitution case, so a blocker inside backticks (e.g. `gh repo delete ...`) passes unflagged. GitHub mirror: #312
issueresolvedmajoriss-2608270500192596
abcd guard tokenizer has no backtick command-substitution case, so a blocker inside backticks (e.g. gh repo delete ...) passes unflagged. GitHub mirror: #312
Frontmatter
| id | iss-2608270500192596 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608270500192596-abcd-guard-tokenizer-has-no-backtick.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-148guard registry coverage gaps found while wiring itd-103 (registry content, not matching semantics): a push whose refspec carries a leading plus is a force in disguise and no entry describes it; xargs, timeout and exec are absent from the matcher's wrappers set, so a hazard launched through one of them is not seen; a backtick command substitution is not followed, while the dollar-paren form is; and a wrapper that IS in the set defangs an entry the moment it carries its own flags, because only the wrapper name is stepped over — `sudo <hazard>` is seen, `sudo -u bob <hazard>` is not, and the same holds for `env -i` and `time -p`. That last one is the sharpest: it turns an entry the registry does describe into an allow with one extra token, and it is the only item here that a facilitator would reasonably assume was covered. Candidates for the admission gate as the registry grows from reality; the wrapper-flag item is matcher-side (`commandOf` in internal/core/guard/match.go), not registry content.