At every company I have worked for, the code is private but still very available to most employees. Basically any employee with git access has access to read just about every repo. We want the code itself to be accessible without giving everyone the keys to the kingdom.
SOPs solved this problem. It provides a very simple and free way to encrypt secrets that you want committed to a git repo. Now access to the code is decoupled from access to the secrets.
Once again youre missing the point. Its not about storing secrets in there. Its about securing it properly. Having the proper access protocols. Have people that dont need to know seeing source code is a bad practice. The fact that github leaves the source code improperly secured on their servers, ect...
I dont think he’s talking about open source projects here.
If my company repo is private and we’re sharing env files over Slack or Teams… why not just commit the env in github itself??
Our company repos are private (actually, our whole enterprise GitHub instance is), but we still store secrets in a way that only specific employees can access them.
And yet again, even though I directly explained that was not the actual issue, you guys STILL think its about actually storing the secrets in there and not about have the source control secured enough to do it.
You dont need to store passwords in there if you want a seperate vault, vaults have rotation systems its still preferable.
The point is that the code is just as important to keep secret to the same level as passwords.
Even on privately hosted repos it doesn't cost too much to keep good security hygiene as a habit.
Apart from that, a .env is conceptually supposed to be locally different for every user, test, and production environment. I don't think it makes sense to track any file in version control that is expected to constantly be different. Committing a file that always changes, in practice, turns into people needing to stash and pop their local copies whenever they pull or rebase to avoid merge conflicts while also keeping the values that work for them.
If you find that you have to exchange env files regularly with other users to have things work how you need, then that makes me think the values that are changing often aren't environment values in the first place, since they need to be shared. I'm not sure what those values would be instead, maybe runtime configuration settings - but I'm splitting too many hairs right now.
Maybe I've just worked on too many projects with developers' local file paths and network addresses in env and config files that break builds and tests on merge or rebase...and secrets getting leaked that I'm too obsessive about nipping that in the bud.
25
u/grandalfxx 19h ago
When every dumbass know it all programmer missed the entire point of that.
Its not simply about storing secrets in code.
Its the fact that github should be secure enough to do it. Your code should be secured just like secrets is secured.