Show HN: enveil – hide your .env secrets from prAIng eyes
21–30 of 152 posts
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#22¹ https://github.com/hodgesmr/agent-fecfile?tab=readme-ov-file...
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#23Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#24I think it would be best if AI agents would honor either .gitignore or .aiexclude ( https://developers.google.com/gemini-code-assist/docs/create... ).
A suitably motivated AI will work around any instructions or controls you put in place.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#25Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#26I think it would be best if AI agents would honor either .gitignore or .aiexclude ( https://developers.google.com/gemini-code-assist/docs/create... ).
The problem is, you cannot force the agent to do anything. A suitably motivated AI will work around any instructions or controls you put in place.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#271Password has this feature in beta. [1] [1]: https://developer.1password.com/docs/environments/
1P will conceal the value if asked to print to output.
I combine this with a 1P service account that only has access to a vault that contains my development secrets. Prod secrets are inaccessible. Reading dev secrets doesn't require my fingerprint; prod secrets does, so that'd be a red flag if it ever happened.
In the 1P web console I've removed 'read' access from my own account to the vault that contains my prod keys. So they're not even on this laptop. (I can still 'manage' which allows me to re-add 'read' access, as required. From the web console, not the local app.)
I'm sure it isn't technically 'perfect' but I feel it'd have to be a sophisticated, dedicated attack that managed to exfiltrate my prod keys.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#28So really all you’re doing is protecting against accidental file ingestion. Which can more easily be done via a variety of other methods. (None of which involve trusting random code that’s so fresh out of the oven its install instructions are hypothetical.)
There are other mismatches between your claims / aims and the reality. Some highlights: You’re not actually zeroizing the secrets. You call `std::process::exit()` which bypasses destructors. Your rotation doesn’t rotate the salt. There are a variety of weaknesses against brute forcing. `import` holds the whole plain text file in memory.
Again, none of these are problems in the context of just preventing accidental .env file ingestion. But then why go to all this trouble? And why make such grand claims?
Stick to established software and patterns, don’t roll your own. Also, don’t use .env if you care about security at all.
My favorite part: I love that “wrong password returns an error” is listed as a notable test. Thanks Claude! Good looking out.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#29Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#30I think it would be best if AI agents would honor either .gitignore or .aiexclude ( https://developers.google.com/gemini-code-assist/docs/create... ).
The problem is, you cannot force the agent to do anything. A suitably motivated AI will work around any instructions or controls you put in place.