InterEnv
github.com/bharathcoorg/interenv- Category
- Developer Tools
- Rank
- No. 3482Tools index
Previous survey · No. 3325 ·
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Security & Identity
- Interfaces
- CLI · Client SDK
- GitHub
- 1 stars
- Latest release
- v1.0.1
- Date
About
InterEnv is a Rust CLI and multi-language SDK that encrypts .env secrets into a hardware security enclave (Apple Secure Enclave, TPM 2.0/Windows Hello, or Linux Secret Service) instead of storing them as plaintext files. Secrets are decrypted only into volatile process memory for the duration of a command, the original .env is securely shredded with DoD-standard multi-pass overwrite, and a Git pre-commit hook blocks accidental secret commits.
What it does
InterEnv replaces the loose configuration file of API keys and passwords with a sealed lockfile that is safe to check in. A random master key encrypts the values, and that key lives in the strongest store the machine offers: a chip-backed keystore when one is available, otherwise the operating system's keychain, or a passphrase for headless runners. To use the values you prefix your usual launch command; the tool unseals them, starts the program with a stripped-down set of variables plus your keys, and applies an operating-system sandbox to that child.
Why it's ranked here
The source is more careful than the pitch. Each lockfile authenticates its own metadata, so swapping the provider label or project identity breaks decryption, and the code refuses a downgrade to the older unauthenticated format. Dependencies are pinned to exact versions, inputs are size-capped, and the threat model spells out what is out of scope, including root compromise and a program leaking its own variables. MIT licensed, with packages for Rust, npm, PyPI, Packagist and Go. The catch: several documents disagree with the code they describe.
What's good
Launching a program is locked down in specific ways. The child gets a short allowlist of ambient variables, relative directories are dropped from the search path, and a command that does not resolve from an absolute directory is refused. On Linux a syscall filter denies debugger attachment, cross-process memory reads, namespace changes and kernel module loading, with a regression test guarding against an earlier version where that filter silently did nothing. The file wiper refuses symbolic links, and a test checks that the link target survives.
Tradeoffs
Documentation drift matters in a security tool. The README promises passphrase derivation at 19 MiB and two iterations; the code uses 64 MiB, three iterations and four lanes. One security document lists four blocked syscalls where the code blocks seventeen, and names a Linux hole-punching call the code does not make. The README implies setting the passphrase variable is enough for CI, but the code ignores it unless a second CI flag is also set. The threat model describes an unreleased hardening branch and defers release signing and software bills of materials. Linux TPM support is off by default.
How to use it well
Fits a solo developer or small team who keeps keys in a local file and wants them off disk without adopting a cloud vault. Lock once per machine, then prefix dev servers and test runners. For CI or moving to a new machine, use passphrase mode and set the extra CI flag, or the variable is ignored. Build with the TPM feature on Linux if you want the chip-backed path there. The commit guard is local and skippable, so keep server-side scanning. Do not count on the wipe on SSDs or snapshotting filesystems; the project says so itself.
Technical notes+
src/main.rs handles lock by generating a random 32-byte key, sealing it via the enclave provider (or Argon2id in passphrase mode), hashing key names with SHA-256 before storing them, and encrypting the JSON map with encrypt_payload_with_aad over the lock's authenticated metadata; legacy lockfiles are decrypted once and rewritten as v4, and a v4 file relabeled as legacy is rejected. It caps sources at 16 MiB, 4096 keys and 1 MiB per value. src/crypto/cipher.rs uses XChaCha20-Poly1305 with 24-byte OsRng nonces. src/crypto/kdf.rs sets Argon2id to m=64 MiB, t=3, p=4, contradicting README.md (19 MiB, 2, 1). src/runner/exec.rs clears the environment to a fixed allowlist, filters PATH to absolute entries, and installs src/runner/linux_seccomp.rs in pre_exec: 17 syscalls return EPERM, default allow. src/enclave/fallback.rs reads INTERENV_PASSPHRASE only when INTERENV_CI=1. src/shredder/mod.rs does 0x00, 0xFF and random passes, refusing symlinks, as tests/symlink_attack.rs checks; docs/SECURITY_MODEL.md cites PUNCH_HOLE where the code uses FALLOC_FL_ZERO_RANGE.
Observed
- License
- MIT
- Language
- Rust, 2021 edition, minimum Rust 1.75
- Interfaces
- CLI (lock, run, edit, show, status, doctor, hook, shred) plus Node, Python, Go and PHP client SDKs
- Packaging
- crates.io, npm, PyPI, Packagist, Go modules, prebuilt binaries and a container image
- Cipher
- XChaCha20-Poly1305 with 24-byte random nonces and authenticated lockfile metadata
- Passphrase KDF in code
- Argon2id, 64 MiB memory, 3 iterations, parallelism 4
- Linux TPM
- Optional tpm build feature, off by default; Secret Service used otherwise
- Runtime isolation
- Linux seccomp deny-list, macOS sandbox profile, Windows Job Object
- Input limits
- 16 MiB source file, 4096 keys, 1 MiB per value
- Tests
- Integration tests directory including symlink-attack and shredder tests
Read from README.md, Cargo.toml, THREAT_MODEL.md, docs/SECURITY_MODEL.md, src/main.rs, src/crypto/cipher.rs, src/crypto/kdf.rs, src/envfile/parser.rs, src/runner/exec.rs, src/runner/linux_seccomp.rs, src/enclave/fallback.rs, src/shredder/mod.rs, tests/symlink_attack.rs, LICENSE.
What it can do
Encrypt .env secrets into a hardware security enclave (Secure Enclave, TPM, or Linux Secret Service)
.env file → Encrypted secret stored in hardware enclave
Decrypt sealed secrets into volatile process memory for the duration of a command
Encrypted secrets → Decrypted secrets in process memory
Securely shred the original .env file with DoD-standard multi-pass overwrite
.env file → Securely erased file
Run a command with decrypted secrets injected into its environment
Command, encrypted secrets → Command execution with secrets available
Edit sealed secrets via CLI
Secret name/value → Updated encrypted secret
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.