3.7 KiB
PRD 0038: smolmachines Env Contract and Secret-Safe Injection
- Status: Active
- Author: didericis-codex
- Created: 2026-06-02
- Issue: #135
Summary
Make smolmachines env handling match Docker's contract: resolve manifest env
entries through resolve_env(), keep secret and interpolated values out of
host argv, and document or enforce an explicit env contract for the backend.
Problem
bot_bottle/backend/smolmachines/prepare.py builds the guest env from
bottle.env directly, bypassing resolve_env(). Entries like ?prompt and
${HOST_VAR} can reach the guest literally rather than being prompted or
resolved. In contrast, Docker resolves env through resolve_env() before
writing a mode-600 env file.
smolmachines/smolvm.py renders env as -e KEY=VALUE on smolvm machine create argv, and SmolmachinesBottle.agent_argv / exec prepend
env KEY=VALUE … onto the smolvm machine exec argv. Any literal or resolved
secret value is therefore visible in the host process table.
The two backends have no shared env contract document. Divergence will silently widen as new manifest env features are added.
Goals / Success Criteria
- Manifest env entries are resolved through
resolve_env()before being injected into the smolmachines guest, matching Docker behaviour. - No manifest env value (literal or resolved) appears on host argv during machine creation or exec.
- Define and document an explicit smolmachines env contract covering literals,
?promptsecrets, and${HOST_VAR}interpolations. - Unit tests cover: literal passthrough, prompted-secret resolution, host-var interpolation, and the no-argv-leak invariant.
Non-goals
- No changes to the Docker env path.
- No changes to manifest schema or
resolve_env()itself. - No changes to smolmachines networking or mount handling.
- No new runtime dependencies.
Scope
In scope:
bot_bottle/backend/smolmachines/prepare.pyenv resolution.bot_bottle/backend/smolmachines/smolvm.pymachine-create argv.bot_bottle/backend/smolmachines/bottle.pyagent_argv/execenv injection.bot_bottle/env.pyif helper changes are needed to support the smolmachines path.- Unit tests in
tests/unit/covering the above.
Out of scope:
- Integration tests that start a live smolmachines VM.
- Docker backend changes.
- Dashboard or CLI changes.
Design
Run smolmachines env through resolve_env() at prepare time, exactly as Docker
does. After resolution, inject env into the guest through a mechanism that does
not expose values on host argv — for example by writing a mode-600 env file
into the machine's state directory and loading it at exec time, or by passing
env through smolvm's stdin if the tool supports it.
If smolvm provides no stdin or env-file injection path, document this as a
known limitation and at minimum move env values behind a per-invocation
tmpfile rather than inline argv.
The env contract for smolmachines should mirror Docker's:
- Literals: passed as-is after resolution.
?promptentries: prompted at prepare time; resolved value injected, never on argv.${HOST_VAR}entries: interpolated from the operator's env at prepare time; resolved value injected, never on argv.
Testing Strategy
- Unit tests for
prepare.pyassertingresolve_env()is called and that resolution results are used rather than rawbottle.envvalues. - Unit tests for
smolvm.pymachine-create argv asserting no env value appears inline. - Unit tests for
bottle.pyexec path asserting the same argv invariant.
Run:
python3 -m unittest tests.unit.test_smolmachines_preparepython3 -m unittest discover -s tests/unit
Open Questions
- Does
smolvm machine createsupport an env-file flag or stdin injection that avoids-e KEY=VALUEargv?