5 ms·

Wait do people not use .env files? I've aliased "gitinit" to make a .env file, .gitignore that ignores env nodemodules etc, then runs git init

bifrost 8y ago
If its harder than putting something in a file, people usually don't use it...
- giancarlostoro 8y ago
  If it's not default behavior even less people use it.
  - bifrost 8y ago
    Exactly right. The default behavior has to change, but thats probably going to be an uphill battle. Its easier to protect users from their own mistakes than to change years of habits though.
sbov 8y ago
Since there's no standard, presumably different people use different methods, or sometimes none at all. Beyond that, people could still make a mistake and put something in code that belongs in an env file.
- SwiftyBug 8y ago
  Honest question: where should I put that env file?
  - peterwwillis 8y ago
    You can keep a .env.default or .env.sample in your repo, but never use it directly. It should only document what the available parameters are. Using a .env file is a bit of an anti-pattern, partly because many applications expect it and thus will be affected by it in ways you might not want. But also because passing configuration to applications via environment is not great, because then the values ar all static and the only way to change them is to restart the app. Better to have a function that can reload a real data format (json, yaml, ini) at run-time. Each environment that runs your app will need to have its own 'env file' because every environment is slightly different, and they're coupled to deployments. So I'd keep your environment stuff wherever your deployment stuff is; with your terraform/ansible/puppet/chef configs, or etc/consul, or an S3 bucket, or SSM, etc. Create it at deploy time, pull it into the app at run time.
33degrees 8y ago
sometimes people use .env files, and then share them with other developers using a publicly accessible paste service like gist (I'm not kidding)
scarface74 8y ago
There is no excuse to ever have AWS secret keys anywhere in your code or your settings. If you are running locally, you should be using your own secret keys that are configured in your user directory with aws configure If you are running on anything within AWS you should be using a role attached to your EC2 instance or lambda and the SDK can retrieve your keys automatically. Unfortunately, every single third party code sample on the internet has you including the secret keys in your code.
- i_am_nomad 8y ago
  An employee of mine once committed a keypair for our company GSuite, clearly labeled, in a Python script. I asked her to remove it from the repo, and she simply pushed a new version of the file with the keypair gone. Plus, she hadn’t configured .gitignore, so all the binaries were there too.
  - inimino 8y ago
    The right request would have been to revoke it, not to try to remove it from the repo.
alain_gilbert 8y ago
One must be careful if they use docker. I have seen people doing this in their Dockerfile ADD . /src To add all the sources in the image, and inadvertently just made public all the secrets that were in the .env file. Personally, I like to keep all my secrets very far from my repository.

bifrost 8y ago

If its harder than putting something in a file, people usually don't use it...

giancarlostoro 8y ago
If it's not default behavior even less people use it.
- bifrost 8y ago
  Exactly right. The default behavior has to change, but thats probably going to be an uphill battle. Its easier to protect users from their own mistakes than to change years of habits though.

sbov 8y ago

Since there's no standard, presumably different people use different methods, or sometimes none at all. Beyond that, people could still make a mistake and put something in code that belongs in an env file.

SwiftyBug 8y ago
Honest question: where should I put that env file?
- peterwwillis 8y ago
  You can keep a .env.default or .env.sample in your repo, but never use it directly. It should only document what the available parameters are. Using a .env file is a bit of an anti-pattern, partly because many applications expect it and thus will be affected by it in ways you might not want. But also because passing configuration to applications via environment is not great, because then the values ar all static and the only way to change them is to restart the app. Better to have a function that can reload a real data format (json, yaml, ini) at run-time. Each environment that runs your app will need to have its own 'env file' because every environment is slightly different, and they're coupled to deployments. So I'd keep your environment stuff wherever your deployment stuff is; with your terraform/ansible/puppet/chef configs, or etc/consul, or an S3 bucket, or SSM, etc. Create it at deploy time, pull it into the app at run time.

33degrees 8y ago

sometimes people use .env files, and then share them with other developers using a publicly accessible paste service like gist (I'm not kidding)

scarface74 8y ago

There is no excuse to ever have AWS secret keys anywhere in your code or your settings. If you are running locally, you should be using your own secret keys that are configured in your user directory with aws configure If you are running on anything within AWS you should be using a role attached to your EC2 instance or lambda and the SDK can retrieve your keys automatically. Unfortunately, every single third party code sample on the internet has you including the secret keys in your code.

i_am_nomad 8y ago
An employee of mine once committed a keypair for our company GSuite, clearly labeled, in a Python script. I asked her to remove it from the repo, and she simply pushed a new version of the file with the keypair gone. Plus, she hadn’t configured .gitignore, so all the binaries were there too.
- inimino 8y ago
  The right request would have been to revoke it, not to try to remove it from the repo.

alain_gilbert 8y ago

One must be careful if they use docker. I have seen people doing this in their Dockerfile ADD . /src To add all the sources in the image, and inadvertently just made public all the secrets that were in the .env file. Personally, I like to keep all my secrets very far from my repository.