Good, but secretspec is more powerful.
Show HN: enveil – hide your .env secrets from prAIng eyes
131–140 of 152 posts
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#132On my current project, we've settled on a system that reads environment variables from Hashicorp Vault, interpolates the variables into placeholders in config files, and then loads the processed config files in the app in memory. It works really well, is convenient to manage secrets for multiple environments and keeps the secrets off of the disk everywhere.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#133Earlier quoted context omitted.
This is amazing. I agree with your take except "You’re not actually zeroizing the secrets"... I think it is actually calling zeroize() explicitly after use. Can I get your review/roast on my approach with OrcaBot.com? DM me if I can incentivize you.. Code is available: https://github.com/Hyper-Int/OrcaBot enveil = encrypt-at-rest, decrypt-into-env-vars and hope the process doesn't look. Orcabot = secrets never enter…
I think we're both right about zeroize. Added a reply to clarify. In short, yes, the key and password are getting zeroized, but not the actual secrets. Which seems like the thing that matters in this context, at least given the tool's stated aims. OrcaBot: There's a lot there! Ambitious project. Cute name, who doesn't love orcas? I don't see anything screamingly bad, of the variety that would inspire me to write essa…
Thank you! Great feedback. Again agree with you on all points. Will take it onboard!
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#134If an agent isn't trustworthy, why are you using it?
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#135Earlier quoted context omitted.
Your concerns are not entirely unfounded. https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_... I have noticed similar behavior from the latest codex as well. "The security policy forbid me from doing x, so I will achieve it with a creative work around instead..." The "best" part of the thread is that Claude comes back in the comments and insults OP a second time!
Every time someone announces a major ai breakthrough, the utility mode becomes a wall of ai-generated soc3 advice: > SANDBOX YOUR AGENT. Seriously. Run it in a dedicated, isolated environment like a Docker container, a devcontainer, or a VM. Do not run it on your main machine. > "Docker access = root access." This was OP's critical mistake. Never, ever expose the host docker socket to the agent's container. > Use a r…
I just gave it a dedicated `agent` user. So it's free to blow up its own files, but not mine.
(Looked into the docker stuff and realized the only thing I actually cared about was it reading/writing my files and that Unix solved that problem like 60 years ago)
I'm not hooking it up to my email, but I will probably give it its own account that I can forward stuff to.
For most people I think the appropriate way to run it is on a Raspberry Pi (or mac mini, as the trend goes :)
I realized I could fiddle with docker and have constant inconvenience and still stress about did I set it up right.. or just give it its own box (pi or VPS) for $5 and if it blows it up I just reset it.
Having Claude as my sysadmin there is fun too. I obviously wouldn't use that for anything serious though. But in a year or two, that might not even be such a bad idea. At this point reliability is really the missing feature.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#136[dead]
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#137I use bubblewrap to sandbox the agent to my projects folder, where the ai gets free read/write reign. Non-synthetic env cars are symlinked into my projects folder from outside that folder.
How have you been tracking down all the bits and pieces from your operating system that the agent still needs to do what it needs to? I'm working with Java projects and Gradle builds and the list of stuff is getting crazy.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#138Earlier quoted context omitted.
In the context of traditional SaaS, using dynamic secrets loaded at runtime (KMS+Dynamo, etc.). For agentic tools and pure agents, a proxy is the safest approach. The agent can even think it has a real API key, but said key is worthless outside of the proxy setting.
It suprises me how often I see some Dockerfile, Helm, Kubernetes, Ansible etc write .env files to disk in some production-alike environment. The OS, especially linux - most common for hosting production software - is perfectly capable of setting and providing ENV vars. Almost all common devops and older sysadmin tooling can set ENV vars. Really no need to ever write these to disk. I think this comes from unaware deve…
The problem isn't the .env file itself but using environment variables at all to pass secrets is insecure.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#139https://github.com/jdx/fnox A recent project by the creator of mise is related too
This would be perfect if it also was able to expose secrets as files scoped to the process ala /run/secrets/secret_name.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#140https://github.com/getsops/sops This software has done this for years
We just recently adopted this and it's crazy to me how I spent years just copying around gitignored .env files and sharing 1password links. Highly underrated tool.
For a long time up until about a couple of years ago the project was stagnated and was missing some pretty critical features. I'd say it was only halfway usable until then and it doesn't have near the ecosystem that things like Hashicorp Vault does. But for my self hosted infra stuff it is perfect. It just really doesn't gel well with compliance frameworks and audits, mainly because the auditability of the solution goes out the window the second someone is able to decrypt the secret - its access patterns are untraceable. These auditors really prefer to see a situation where access to the secret is tightly controlled and audited on rotation and sops, by nature of how it works, cannot really easily offer that.