Live data from Hacker News

Show HN: enveil – hide your .env secrets from prAIng eyes

github.com

21–30 of 152 posts

Re: Show HN: enveil – hide your .env secrets from prAIng eyes

#24

I 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

#26

I 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.

It doesn’t even need to be motivated: just forgetful.

Re: Show HN: enveil – hide your .env secrets from prAIng eyes

#27

1Password has this feature in beta. [1] [1]: https://developer.1password.com/docs/environments/

You can already put op:// references in .env and read them with `op run`.

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

#28
This suffers from all the usual flaws of env variable secrets. The big one being that any other process being run by the same user can see the secrets once “injected”. Meaning that the secrets aren’t protected from your LLM agent at all.

So 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

#30

I 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.

You can force what is not able to git upstream.
Post reply on HN