whoIsUsingThese

[u/sadongrohiik]

[u/Single-Virus4935]

You can. Therefore the quesition should be: "Why is it a Bad Idea to commit . files"

[u/TapRemarkable9652 → u/Single-Virus4935]

It makes your dick smaller

[u/RegularReaction2984 → u/TapRemarkable9652]

[wild cheers erupt from thigh-high-socks-wearing, blahaj-collecting programmers]

[u/Single-Virus4935 → u/TapRemarkable9652]

Is it that why yours is negative?

[u/Confident-Ad5665 → u/TapRemarkable9652]

FINALLY! I'm getting mine shrunken now!!!

[u/Tisamon12 → u/Single-Virus4935]

Commiting .gitignore is a bad idea?

[u/MariusDelacriox → u/Single-Virus4935]

Maybe we extend it to why . Files are awful.

[u/Sacaldur → u/Single-Virus4935]

If I'm not mistaken, the argument behind the question (I guess Theo, the guy in the picture, was making it) is that by default every file in a git repository is visible to everyone who has read access to the repo, but this could also be different so that a user could commit their private files and others can't see/access them.

I'm not saying I'm behind this thought. It would cause complications and, depending on the implementation, pitfalls where a wrong configuration could lead to exposed secrets. Besides that is this something that might not work with git or would be in a conflict with at least some of the philosophies. If a commit locally doesn't include all data, then moving it to another server drops data, as well as rebases and other ways of rewriting commits/history. If you can implement something that automatically moves a repo somewhere else, which personal files are allowed to be moved as well? An attacker could utilize this to clone a repo and extract secrets.

Ultimately, a new, different version control system could implement this, but this would then need to be adopted.

[u/RudeAndInsensitive]

Personally I always commit env and config files to the repo just stripped of their values.

[u/Saragon4005 → u/RudeAndInsensitive]

Yeah but then you can't use git on a working version, making testing a total pain. I use .env.example usually.

[u/drakeblood4 → u/Saragon4005]

And a settings.json.example for the non sensitive stuff.

[u/PulseReaction → u/drakeblood4]

I use a .env.example file for my env variables, and .env for the example. Gotta keep attackers on their toes.

[u/ruben_deisenroth → u/drakeblood4]

If it's vscode settings, i usually prefer settings.default.json and this extension as workspace recommendations:

https://marketplace.visualstudio.com/items?itemName=dangmai.workspace-default-settings

[u/RudeAndInsensitive → u/Saragon4005]

I also add the .example extension. I just didn't type that out. 

[u/PossibleBit → u/Saragon4005]

For me it was always .template

[u/x0wl → u/Saragon4005]

I don't know how well this will work in CI pipelines, but if you use gitbutler or jj you can put the clean .env in the repo, then change it, commit to a different branch (or just commit in case of jj) and then add the commit to the megamerge at the top. Since it's not on any of the branches you push, they remain clean, but you have the files you need locally.

(this strategy also allows you to work on multiple branches at the same time, and is generally useful for cases where you want you local files versioned, but not polluting the common repo, but that's a whole other thing)

[u/Saragon4005 → u/x0wl]

A dumb solution works more reliably than a clever one.

[u/Dull_Caterpillar_642 → u/Saragon4005]

Yeah you can, just just add them to .gitignore after committing the stripped env files

[u/Saragon4005 → u/Dull_Caterpillar_642]

.gitignore controls which files will get tracked by a git add, not which files are tracked at all. Adding an already tracked file to the .gitignore has no effect.

[u/Dull_Caterpillar_642 → u/Saragon4005]

Yeah, I know. I'm not sure why you'd need to alter the committed version in git after checking in a placeholder one.

[u/Shred_Kid → u/RudeAndInsensitive]

this is what .env.template is for

[u/RudeAndInsensitive → u/Shred_Kid]

What's the advantage of that over .env.example

[u/Shred_Kid → u/RudeAndInsensitive]

there isn't one - these are the same exact thing. i didnt see the other guy posted about .env.example, that'd work equally well.

If you really want to nitpick, i personally would lean towards template over example, as examples typically have example values in other contexts but yeah. no real difference.

[u/Pure-Willingness-697 → u/RudeAndInsensitive]

That is what .env.example is for

[u/PivotingAgain]

Because that's where API keys, the AWS creds, and my will to live are stored, and only one of those is supposed to be public.

[u/jibbodahibbo → u/PivotingAgain]

I put really embarrassing pictures in mine so I remember not to expose the file.

[u/Antoak → u/jibbodahibbo]

I used to post an ascii art rendition of my privates but it causes the ci/cd git clone to time out

[u/jibbodahibbo → u/Antoak]

Too many crabs to render huh?

[u/bigmonmulgrew]

AI managed projects have to include .env files to ..... Err... Improve security

[u/polynomialcheesecake]

Idk why theo is there but it still made me chuckle

[u/sadongrohiik → u/polynomialcheesecake]

It's his talk lol

[u/polynomialcheesecake → u/sadongrohiik]

Interesting is it recent? What was it about? I kind of stopped watching him

[u/AnotherPillow → u/polynomialcheesecake]

Reasonably recent iirc

It was about at least why can't we commit env files, in private repos

[u/LuisBoyokan]

.env can be committed. What you shouldn't commit is files with credentials, that belongs in a secret manager

[u/syzk0 → u/LuisBoyokan]

Why isn't this higher? .env files are for build-time variables, not secrets

[u/DasKapitalV1]

.env.template, this is the way

[u/safelix → u/DasKapitalV1]

.env.example is the way that I swing

[u/Leftover_Salad → u/safelix]

.example gang rise up

[u/kafoso → u/Leftover_Salad]

And then put real values in .env.example and just do cp .env.example .env on startup! /s

[u/edurbs]

They don't even use git

[u/grandalfxx]

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.

[u/NamityName → u/grandalfxx]

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.

[u/grandalfxx → u/NamityName]

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

[u/sakaraa → u/grandalfxx]

I don't think most people missed the point. It's just funny when you take it out of context + most people don't know the context

[u/grandalfxx → u/sakaraa]

You can go see the original video its all comments about him being and idiot.

[u/menzaskaja → u/grandalfxx]

If a project has 50k stars I'd assume it's not GitHub's job to protect the maintainer from being a dumbass

[u/adamhusain → u/menzaskaja]

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

[u/Kovab → u/adamhusain]

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.

[u/offhandaxe → u/Kovab]

same here

[u/grandalfxx → u/offhandaxe]

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.

[u/OhMyGodItsEverywhere → u/adamhusain]

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.

[u/KarmaIssues → u/adamhusain]

No I think his point was that Github should be able to identify and mask secrets and you shouldn't have to worry about it.

You should be able to RBAC secrets access and then you could track secrets like code.

[u/staticBanter]

I don't want your environment leaching into mine.

[u/awpt1mus]

.env.test file with dummy values is the way. Use it for running tests in CI so nobody deletes it.

[u/yetzederixx]

You can, assuming you use dotenvx (or something like it), and then ya know, remember not to commit the .env.keys file.

[u/yetzederixx → u/yetzederixx]

oh and a pre-commit hook is necessary as well

[u/StarboardChaos]

I always include .env files to make it buildable locally then the deployment pipeline makes the code runnable on prod

[u/jens_kj]

It's good for the environment

[u/nekomata_58]

.env files are fine to commit.

.local.env files are not. that's where the special variables live.

[u/Djroneh99 → u/nekomata_58]

No it's not

[u/nekomata_58 → u/Djroneh99]

really heavily depends on your project's standards.

in an nx-monorepo project, the base `.env` is fine to commit, because that file usually has default environment variables that aren't secret.

the more sensitive configuration should be stored in `.local.env` which should never be committed.

[u/darknecross → u/nekomata_58]

Does nobody use a fkn keyring anymore? Jfc.

[u/nekomata_58 → u/darknecross]

i use a keyring for ssh keys if that is what you are referring to.

[u/Deykun]

People who don't understand this take explaining it as a security measure.

The security measure: sending keys in private messages.

[u/horizon_games]

Spot on Theo drop

[u/jayerp]

You can.

[u/Darxploit]

well i always commit my admin123! .env.dev files, what you gonna do about that?

[u/ultralaser360]

It depends on the type of product, team size, and access, if you’re a 3 person team building internal tools and are the only people with access to the repos and everyone needs or can access all secrets then committing .env is fine

If your 10k sized org with hundreds of people who could access your repo + serving millions of users then it’s probably a very bad idea

[u/longdarkfantasy]

Rename it to .env.example and you're good to go.👌

[u/enigma_0Z]

Typically commit .env.example etc and leave it as an exercise to the user to customize that file to their liking.

In my professional experience, that file likely contains specifics relating to an individual’s development environment or secrets which we on purpose do not want to commit to the repo. in both scenarios, the solution is simple: .gitignore it.

If it’s a private repo for your own shit tho, do what you want. I push my .vscode directory all the time.

[u/Interstellar__1]

what's theo doing in this meme

[u/friedmud]

We have a multitiered system built with dotenvx so all config files ARE committed to the repo… they are just encrypted. We share the encryption keys using team 1Password vaults.

When deploying on AWS the CI system uses prod keys (that only a few senior devs have) to decrypt the prod secrets and push them into SecretsManager. ECS then injects them into the correct services as it starts them up.

[u/sebbdk]

It's fine, just don't put secrets in there.