Fixed
kuma vm's disks carry the declaration's shell again when kuma runs inside a distrobox. The one podman call invmthat spawned a private process did not escape the container kuma itself runs in, so inside one it never found the tag it was asked about, and every failure of that call is silent by design, so the fallback read as "no shell" and nothing could tell. It goes through the same escape every other podman call takes, which is where it always should have been.- A name capture cannot declare is refused when it is named, before it is echoed anywhere.
kuma capturenarrows to names you type, and its dry run repeats those names inside the suggested command, the one action in the JSON document an agent is invited to run. A name the declaration could never hold, one carrying shell metacharacters for instance, rode into that suggestion as itself and was refused only later, by the write it would have broken. The names now pass the same alphabet the two lists capture writes enforce, before anything runs. - The widen that opens a staged directory to root pruned its credentials with a
-pathpattern, and a glob pattern is what that is: a*,?or[in the path to a credential (TMPDIR is yours to set) would not match the file it named, the prune would miss, and the password hash or restore secret would be widened world-readable for the length of the run. The pattern is now the escaped literal path, and a test runs the realfindagainst a directory named to try it.
Changed
kuma capture --json's dry run says"dry_run": true, like every other gated verb's. It shipped without the field since the verb was born, so an agent reading the document had to infer a preview from"written": false. The document is otherwise unchanged.kuma switchandkuma rollbackdry runs print the command they preview in the same→form every other dry run uses, rather than leaving it implicit in the prose.kuma diffno longer runsbrew listto see what is installed: the Cellar directory says the same thing, and reading it saves the spawn on every run. The barekumaprobe already read it that way.
Static x86_64 binary, no runtime dependencies.
$ curl -LO https://github.com/Letdown2491/kuma-linux/releases/download/v0.20.0/kuma-x86_64-unknown-linux-musl
$ chmod +x kuma-x86_64-unknown-linux-musl && sudo mv kuma-x86_64-unknown-linux-musl /usr/local/bin/kumaVerify it came from this workflow:
$ cosign verify-blob \
--bundle kuma-x86_64-unknown-linux-musl.bundle \
--certificate-identity-regexp '^https://github.com/Letdown2491/kuma-linux/' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
kuma-x86_64-unknown-linux-muslBuilt from 241dc76bdd146409a88cdd1ac6e452af74ff5e27.