upvote

points

by KevinMS2 days ago |
comments
upvoteby s_dev6 hours ago|
next
[-]
The fact that it's hidden means it doesn't get commited by accident in most git repos unless explicitly added or configured that way.
reply
upvoteby deathanatos4 hours ago|
parent|
next
[-]
No, it won't.

  ~/code
  » cd foo
  ~/code/foo
  » git init
  ± foo:main:/
  » touch .env
  ± foo:main:/
  » git add .
  ± foo:main:/
  » g s
  On branch main
  
  No commits yet
  
  Changes to be committed:
    (use "git rm --cached <file>..." to unstage)
   new file:   .env
  
  ± foo:main:/
  »
File is added, kaboom. "It should be in .gitignore" yes, true, but that has nothing to do with it not getting committed because it is hidden.

And even with it in .gitignore, I've dealt with multiple security incidents where someone has managed to commit it anyways. (And yes, I'm aware there are commands to do this, but what I haven't figured out is why someone would work around the safety and not think "what's the point of this?" prior to the bullet ending up in the foot.)

reply
upvoteby fhn5 hours ago|
parent|
prev|
[-]
there shouldn't be any secrets in it so committing it shouldn't be a huge problem.
reply
upvoteby BigTTYGothGF3 hours ago|
parent|
[-]
> shouldn't

Granted, but on the other hand: the entire history of this profession.

reply
upvoteby jerf6 hours ago|
prev|
[-]
I hate that it's hidden too. There's no reason for it to be hidden and arguably some reason for it not to be hidden.

I did discover one reason for it not to be just "env" though, which surprised me, which is that "source env" will yield "bash: source: /usr/bin/env: cannot execute binary file". I did not expect the source command to use the $PATH to resolve the filename. Probably some minor security issues that can result from that out there in the world. Arguably anyone loading it should use "source ./.env" or equivalent, with full path.

It's documented in the bash manual, of course. But it is rather complicated as to when it will and will not use $PATH.

reply