Hacker News Reader

Comment by michaelmior | Hacker News Reader

With leaking secrets being such a big concern, it seems wise to require that secrets be encrypted to use dotenvx. That is, it will only work with encrypted secrets. As others have commented, this doesn't eliminate the risk entirely, but I think having a tool that doesn't support unencrypted secrets at all, although a bit less convenient, is a win.

View on HN

Not all env vars are secrets. About half is just regular config. If mandatory how would it know what's a secret?

I'm not sure what the "it" you're referring to is, but if something is not a secret, you could either encrypt it anyway or use an alternate mechanism to provide the value.

Encrypted with what key? Do you just mean obscured?

The utility has a means of encrypting them with public key cryptography so that the plaintext is never in your development directory. GP thinks this should be made mandatory.

point is: where and how you do get this key when in prod?

The "securest" way is, you start your app and the app awaits the input of the key, it is only in the RAM.

But in reality, nobody will do that.

Part of my point is that if you care about security, you need to be thinking about these things. Forcing encryption then also forces you to think about how to provide the key. Of course, it's possible to do this in a very insecure way that defeats the purpose of encryption in the first place, but I think it moves things in the right direction.

There are a lot of ways of doing this, sealed secrets is one, mozilla sops is another.

No, I mean encrypted. I'm not sure what you mean by "obscured", but if you just mean obfuscated in some easily recoverable way without a key, then no. If you read the original post, it describes the mechanism that dotenvx already has in place for encryption.

Reply on news.ycombinator.com