| Filename | Latest commit message | Latest commit date |
|---|---|---|
c857afb8ed
Some checks failed
energy meters on real hardware / RAPL and NVML on jetson-hub (push) Successful in 1m25s
energy meters on real hardware / sink decode table · RAPL on jetson-hub (NVML surveyed) (push) Successful in 3m32s
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (push) Has been cancelled
energy meters on real hardware / sink decode table · per-task energy and the GPU rail on macOS (push) Successful in 2m39s
Workspace::seal runs a tool as itself: a home of its own (owner-only, with its temporary, config, data and cache directories inside), an environment that is exactly that home's variables and a minimal PATH with nothing inherited, and an S1 grant that writes its home and reads only what the workspace shares. One tool can neither read nor write another's home, and no key in the workspace's environment reaches it. Where the host cannot confine a program, sealing is refused rather than claimed: the seal is the confinement, not the directory. SPEC §5.10. The executor gains with_env (the program's whole environment), carried by a new sandbox_meter::run_attributed_in on both the macOS posix_spawn path and the portable one; run_attributed keeps inheriting. Tested under Seatbelt on the iMac with single programs (macOS /bin/sh re-executes another shell, which the confinement rightly refuses): a tool writes and reads its home, another can neither read its token nor plant a file there, and an inherited key does not reach a tool while HOME does (the positive control). Falsified there: an inherited environment, the whole workspace writable, and the whole workspace readable each turn the test red, which also shows the confined branch ran. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| examples | ||
| src | ||
| tests | ||
| Cargo.toml | ||