3 ms·
Why would you have "production secrets" in a .env file in the first place? I feel like that's the real problem here.
by globular-toast 10mo ago
Why would you have "production secrets" in a .env file in the first place? I feel like that's the real problem here.
- deleted 10mo ago[deleted]
- xinbenlv 10mo agoWe use infiscial and other mechanism but hey, wouldn't it be nice to have one less square inch of attack surface?
- globular-toast 10mo agoWhy not have one less square mile of attack surface by not having secrets in a .env file in the first place? What are people doing that requires something like this?
- pjjpo 10mo agoI think it's common to have dev not production secrets there, and am reading the blurb about production secrets as non-local secrets. Even dev keys are a pain if they get leaked. The idea seems nice with a simple yet effective implementation. While I think I currently have a shell script syntax highlight plugin reading env files, it's definitely overkill. Now if only this could protect from random npm packages reading your env files...
- dissent 10mo agoThis implies there's some kind of shared resource out there on the network that your devs are developing on. Why not make all these resources part of your local dev stack, served on localhost, and use dummy credentials? You can even commit them because they're not sensitive.
- pjjpo 10mo agoOk ok, it is indeed keys to AI APIs. I know it's not kosher to admit to that on HN anymore but it's the reality for me at least. Unfortunately local models just can't support development of products using them.
- xinbenlv 9mo agoThanks @pjjpo, exactly. My bad to confuse people, no we don't put real prod-prod credentials in .env. We use mechanisms to ensure separation of secrets. Thank you for saying that it's a simple yet effective implementation. If you try it and let us know your feedback.