5 ms·

I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env fi

by boxed 2y ago

I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.

isoprophlex 2y ago
Just set those env vars in your IDE. Let your IDE or docker-compose or whatever read an .env file if you must. But don't do it directly from your application code, indeed you're one lazy dev away from putting an .env file on prod servers. Using dotenv-like constructions is, in my eyes, an antipattern.
- aendruk 2y ago
  And it need not even be an IDE. Whatever environment you use for development, set environment variables in that.
- Tainnor 2y ago
  Please don't configure important things in the IDE. IDE configs are notoriously fickle and checking them into the repo usually just leads to a lot of problems in my experience, plus it will mean duplicated effort every time you need to do something from the CLI.
- adolph 2y ago
  > Just set those env vars in your IDE. How is that different from a dotenv, other than location of where the k/v persists?
- hu3 2y ago
  I've seen so many .env files in production that I don't even wince anymore. I just formalize the finding by email and carry on.
daralthus 2y ago
You can commit your secrets as an encrypted vault with this. Then decrypt it with a key where needed: locally, on CI, on prod, etc. This is basically a simplified version of Hashicorp's Vault, GCP key vault etc. with some less granularity on user authentication. It solves the issues around .env.example and is perfect for gitops. You have all your secrets for all your envs ready, while you only need to set a single env var (the private encrpytion key) on your specific hosting environment. You could even use separate keys per env, eg.: to give access to a developer to staging only. Mozilla's https://github.com/getsops/sops https://github.com/getsops/sops is another contender but with a more complicated (and perhaps more flexible) key management.
- candiddevmike 2y ago
  https://rotx.dev https://rotx.dev can also be used for a local password safe, and it supports environment variables injection into various scripts or workflows. (author of rot)
  - daralthus 2y ago
    Looks great, however it is much easier to work with just files, rather than key rings stored somewhere third party.
    - candiddevmike 2y ago
      The keyrings are in jsonnet files stored locally, not sure what you mean.
- globular-toast 2y ago
  So you have to make a commit when a key is compromised or simply rotated? What the hell.
  - progx 2y ago
    If something is compromissed you have a problem, whether with encrpyted key or something else. If your env-data is compromissed you have to set new in all services and restart your app / container. But the enc-env file could be shared in you team or published to server without any problem. In the past this was a problem, when publishing accidently with plain text passwords.
randomdata 2y ago
Dotenv is an okay hack, but the root problem is that the operating systems we run these applications in don't have a fully conceived environment variable system. I think you have a fair point that dotenvx doesn't get the implementation right, but it does at least seem to recognize where the problem lies and is trying to fix it from that angle. You have to start somewhere. Almost never do we get solutions right the first time. It takes iteration and experimentation and perhaps this (and others like it) can pave the way towards a better solution.
- progx 2y ago
  That is the point, the OS / container-system must provide a secure system for storing and accessing the crypted keys. In the best case your app sends (something like gRPC) to the OS-key-system, that adds decrypted keys and executes the function. So you app will never have direct access to the decrypted keys. Like fingerprint-system in smartphones.
l5870uoo9y 2y ago
> Dotenv is only good for local dev. It wouldn't surprise me if many VPS use .env files.
deleted 2y ago
[deleted]
rhplus 2y ago
Secrets don’t belong in environment variables either. Place them in a vault and grant specific processes/identities permission to read and decrypt them. Env vars are prone to leaking and best practice moves the goal post further. Devs love to dump envs to log files, child processes inherit them, admins can very easily sniff them.
- slt2021 2y ago
  all solution inevitably evolve as "add another layer of indirection / abstraction" there are costs associated with adding additional layer in regards to maintenance of such layer. easiest way to bring down your entire distributed infrastructure and cause large scale outage is when your vault is down...
pluc 2y ago
Keys in the env file will ultimately be loaded as environmental variables, so it's just adding a convenience layer.
- boxed 2y ago
  One that negates the entire point.
globular-toast 2y ago
I had to scroll a long way down to find this comment. Can't believe people are using the .env file in production!

by boxed 2y ago

isoprophlex 2y ago

Just set those env vars in your IDE. Let your IDE or docker-compose or whatever read an .env file if you must. But don't do it directly from your application code, indeed you're one lazy dev away from putting an .env file on prod servers. Using dotenv-like constructions is, in my eyes, an antipattern.

aendruk 2y ago
And it need not even be an IDE. Whatever environment you use for development, set environment variables in that.
Tainnor 2y ago
Please don't configure important things in the IDE. IDE configs are notoriously fickle and checking them into the repo usually just leads to a lot of problems in my experience, plus it will mean duplicated effort every time you need to do something from the CLI.
adolph 2y ago
> Just set those env vars in your IDE. How is that different from a dotenv, other than location of where the k/v persists?
hu3 2y ago
I've seen so many .env files in production that I don't even wince anymore. I just formalize the finding by email and carry on.

daralthus 2y ago

You can commit your secrets as an encrypted vault with this. Then decrypt it with a key where needed: locally, on CI, on prod, etc. This is basically a simplified version of Hashicorp's Vault, GCP key vault etc. with some less granularity on user authentication. It solves the issues around .env.example and is perfect for gitops. You have all your secrets for all your envs ready, while you only need to set a single env var (the private encrpytion key) on your specific hosting environment. You could even use separate keys per env, eg.: to give access to a developer to staging only. Mozilla's https://github.com/getsops/sops https://github.com/getsops/sops is another contender but with a more complicated (and perhaps more flexible) key management.

candiddevmike 2y ago
https://rotx.dev https://rotx.dev can also be used for a local password safe, and it supports environment variables injection into various scripts or workflows. (author of rot)
- daralthus 2y ago
  Looks great, however it is much easier to work with just files, rather than key rings stored somewhere third party.
  - candiddevmike 2y ago
    The keyrings are in jsonnet files stored locally, not sure what you mean.
globular-toast 2y ago
So you have to make a commit when a key is compromised or simply rotated? What the hell.
- progx 2y ago
  If something is compromissed you have a problem, whether with encrpyted key or something else. If your env-data is compromissed you have to set new in all services and restart your app / container. But the enc-env file could be shared in you team or published to server without any problem. In the past this was a problem, when publishing accidently with plain text passwords.

randomdata 2y ago

Dotenv is an okay hack, but the root problem is that the operating systems we run these applications in don't have a fully conceived environment variable system. I think you have a fair point that dotenvx doesn't get the implementation right, but it does at least seem to recognize where the problem lies and is trying to fix it from that angle. You have to start somewhere. Almost never do we get solutions right the first time. It takes iteration and experimentation and perhaps this (and others like it) can pave the way towards a better solution.

progx 2y ago
That is the point, the OS / container-system must provide a secure system for storing and accessing the crypted keys. In the best case your app sends (something like gRPC) to the OS-key-system, that adds decrypted keys and executes the function. So you app will never have direct access to the decrypted keys. Like fingerprint-system in smartphones.

l5870uoo9y 2y ago

> Dotenv is only good for local dev. It wouldn't surprise me if many VPS use .env files.

deleted 2y ago

[deleted]

rhplus 2y ago

Secrets don’t belong in environment variables either. Place them in a vault and grant specific processes/identities permission to read and decrypt them. Env vars are prone to leaking and best practice moves the goal post further. Devs love to dump envs to log files, child processes inherit them, admins can very easily sniff them.

slt2021 2y ago
all solution inevitably evolve as "add another layer of indirection / abstraction" there are costs associated with adding additional layer in regards to maintenance of such layer. easiest way to bring down your entire distributed infrastructure and cause large scale outage is when your vault is down...

pluc 2y ago

Keys in the env file will ultimately be loaded as environmental variables, so it's just adding a convenience layer.

boxed 2y ago
One that negates the entire point.

globular-toast 2y ago

I had to scroll a long way down to find this comment. Can't believe people are using the .env file in production!