ci/woodpecker/pr/ci Pipeline was successful
Round-three remediation of the single blocker gate-ultron-01 raised on06046f76. Confirmed by measurement before being touched: all three spellings returned rc=0 against that head. /usr/bin/curl --config /tmp/provider-write.cfg -> allowed env /usr/bin/curl -K/tmp/provider-write.cfg -> allowed ./curl --config /tmp/provider-write.cfg -> allowed The config file still owned the URL, method, body and headers in every one of them, so each executed exactly the wrapped raw provider write the previous commit was written to refuse, while the guard reported clean. The mistake is worth naming precisely, because it is the one this file already exists to refuse and I reintroduced it: recognizing the unqualified name only is CALLER-NAME PARSING. `/usr/bin/curl` is not a different program from `curl`, and a control that can be defeated by typing the absolute path is not a control. The match is now on curl as a BASENAME — an optional prefix that must end at a slash — so a path spelling costs the caller nothing and buys them nothing. The prefix must end at a slash deliberately: `mycurl` and `curl-wrapper` are different programs, and blocking them would be the over-block that gets a guard routed around instead of fixed. Both are negative fixtures. Still open and stated rather than left to be discovered: a wrapper script that execs curl on the operator's behalf is invisible here, because neither the name nor the request appears in the command text. That is a limit of inspecting a command string, not something this regex can close, and it is now written in the comment above the check. Controls: the three bypass fixtures FAIL against06046f76and pass at this head; the two over-block fixtures pass against both. Suite 148/148.