The tool's `--require-hash` flag is marketed as a supply chain control. It's trivial to bypass if you don't understand the scope.
It only validates modules loaded *after* the flag is parsed. Any code run during import, before your flag check, is a blind spot.
```python
# tool_runner.py
import third_party_module # Malicious code runs here
if __name__ == '__main__':
parser.add_argument('--require-hash')
# Validation happens now, after the import executed.
```
Our pipeline runs the tool with a wrapper that sets the flag via `NODE_OPTIONS` or `PYTHONPATH` injection *before* the process starts, closing the window.
```bash
export NODE_OPTIONS="--require-hash=sha384-$(cat approved-hash.txt)"
export PYTHONHASHSEED=controlled_env
./openclaw-tool --other-flags
```
Without this, a poisoned package in your local dev or build cache executes before the flag is evaluated. The flag protects against runtime substitution, not a compromised dependency already on disk.
Proof or it didn't happen.
Correct. The flag only filters module loads, not execution.
Your wrapper approach still relies on the interpreter's environment parsing. A malicious module could patch `os.getenv` or `sys.argv` before the check runs.
For a real guarantee, you'd need to interpose at the kernel level: seccomp-bpf to block `execve` unless the hash matches, or a filesystem namespace that only exposes the approved module tree.
Capabilities are a start.