Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
Exactly, like, learn the BASICS of how to use them and you won't do that.
You should have a default gitignore that omits any "dot" files [chances are you don't want any of those to ever commit to your repo]
So yea, newbies make that mistake. Besides, so what?
You add it to gitignore , change all your passwords, and you're fine again.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Software development professional with varied experiences in web development, QA, API and UI testing, CI/CD setups. Committer on docker-selenium and maintainer of docker-seleniarm fork.
@ravavyr, you're fine until another newbie comes into the team and needs to edit .env but makes a backup of it to avoid making a mistake, since it's not in GitHub. Later, when doing a git add . the person forgets that the backup isn't in .gitignore -- he/she may not even know what a .gitignore is -- and accidentally commits the secrets.
This scenario might sound a bit far fetched, but I have seen things like this happen many times. Also, some people will hide the mistake instead of going and changing all the passwords... it's easier to just pretend it didn't happen, that reverting the commit will fix the problem, and that no hackers will ever look at git history. :)
I will say that config servers were initially very intimidating, but once I got used to it, I personally can't imagine going back.
From a security standpoint, it's not perfect though. A tool is still only as good as the people using the tool. We still struggle with how to avoid getting the secrets into the config server. IT has the access, but the devs all have the know-how regarding what the secret is for. Sometimes this means devs create the secret and then share it in the chat system (a bad practice) so that the IT person can then add it in the config server... I guess things can still not make sense even with a config server.
I was strictly referring to your somewhat bold statement:
NO ONE gets hacked via their .env file. Ever.
If your secrets become public, you can absolutely get hacked. Which is why the rule exists: do not commit .env files to your repo. What you do on your local machine is your problem. If you want to use .env there or .myEnvIsBetterThanYourEnv it's all the same.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
If your secrets became public then the env is already irrelevant.
No one gets your secrets from your env unless they've already gotten into your server.
Even the most basic servers have [dot] files blocked from access (or should, i'll admit some don't do it by default)
And yes, if your env got into your repo, changes the passwords and keys and make sure you add it to gitignore so it doesn't happen again.
Either way, the .env file has never been the problem.
If .env is in your repo, it public knowledge. Even if its a private gitlab, nobody keeps track of what secret is where and secrets in repos should therefor always be considered public knowledge.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Exactly, like, learn the BASICS of how to use them and you won't do that.
You should have a default gitignore that omits any "dot" files [chances are you don't want any of those to ever commit to your repo]
So yea, newbies make that mistake. Besides, so what?
You add it to gitignore , change all your passwords, and you're fine again.
Or you can use a config server and never have to worry about that "newbie" making that mistake with a modern solution.
@ravavyr, you're fine until another newbie comes into the team and needs to edit .env but makes a backup of it to avoid making a mistake, since it's not in GitHub. Later, when doing a
git add .the person forgets that the backup isn't in .gitignore -- he/she may not even know what a .gitignore is -- and accidentally commits the secrets.This scenario might sound a bit far fetched, but I have seen things like this happen many times. Also, some people will hide the mistake instead of going and changing all the passwords... it's easier to just pretend it didn't happen, that reverting the commit will fix the problem, and that no hackers will ever look at git history. :)
I will say that config servers were initially very intimidating, but once I got used to it, I personally can't imagine going back.
From a security standpoint, it's not perfect though. A tool is still only as good as the people using the tool. We still struggle with how to avoid getting the secrets into the config server. IT has the access, but the devs all have the know-how regarding what the secret is for. Sometimes this means devs create the secret and then share it in the chat system (a bad practice) so that the IT person can then add it in the config server... I guess things can still not make sense even with a config server.
I was strictly referring to your somewhat bold statement:
If your secrets became public then the env is already irrelevant.
No one gets your secrets from your env unless they've already gotten into your server.
Even the most basic servers have [dot] files blocked from access (or should, i'll admit some don't do it by default)
And yes, if your env got into your repo, changes the passwords and keys and make sure you add it to gitignore so it doesn't happen again.
Either way, the .env file has never been the problem.
If .env is in your repo, it public knowledge. Even if its a private gitlab, nobody keeps track of what secret is where and secrets in repos should therefor always be considered public knowledge.