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