Live data from Hacker News

One in every 600 websites has .git exposed

jamiembrown.com

21–30 of 214 posts

Re: One in every 600 websites has .git exposed

#21
It seems like if you're storing secrets and the like in your code's repo, the solution is to not do that, rather than just putting a bandaid over it by hiding the repo.

Deploy the secrets separately: they don't belong in your site's codebase.

Re: One in every 600 websites has .git exposed

#22

For Apache, Order deny,allow Deny from all Order allow,deny Deny from all https://serverfault.com/questions/128069/how-do-i-prevent-ap...

Would it be safer to not put .git within the reach of the webserver, and separate the development path from the production host path?

Re: One in every 600 websites has .git exposed

#23

The author doesn't give any suggestions for alternative ways to deploy. What are the best practices here? What should operators that currently deploy this way do instead?

I use a separate work folder.

Like this:

  git --git-dir=/foo/bar.git --work-tree=/foo/bar.work init

  git --git-dir=/foo/bar.git config receive.denyCurrentBranch ignore
Then create (and chmod +x): /foo/bar.git/hooks/post-update

  #!/bin/sh
  work_tree=/foo/bar.work
  GIT_WORK_TREE=$work_tree git checkout -f
Then you just create a symlink to the work tree for your website root, or put the work tree there, or whatever, depending on preference. Can't say this is perfect, but it works pretty well for smaller projects.

Re: One in every 600 websites has .git exposed

#24

For Apache, Order deny,allow Deny from all Order allow,deny Deny from all https://serverfault.com/questions/128069/how-do-i-prevent-ap...

Don't you specifically have to configure Apache to allow access to dot directories in the first place? (disclaimer, I didn't read the article... but if access to dot directories were enabled.. ya, .git would be exposed, but I'm pretty sure it isn't the default Apache setting.)

Re: One in every 600 websites has .git exposed

#26

I wonder what would happen if you searched for .svn, too. I'm sure you'd run into the same problem in many places. But would it be more or less likely to occur?

I think less likely. Svn actually had an `export` command, which allowed you to do a checkout of a specific commit with no svn metadata. If someone was actually using svn for deployment, they likely knew about it. (http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html)

Re: One in every 600 websites has .git exposed

#27
Obviously you shouldn't be storing sensitive information in your codebase (I hope everybody knows that), but the problem here is that you might have been way back when you were prototyping and then moved them out of the codebase. It's really common to start a codebase just by hacking something together with hardcoded secrets.

If you have the proper secret segregation now, but you're deploying by doing a git pull, now you run the risk of not really having segregated secrets all over again.

Re: One in every 600 websites has .git exposed

#28
post #13

Earlier quoted context omitted.

I was busy editing it, thanks though. edit: sounded wayyy too snarky lol.

[deleted]

HN does not use standard Markdown. It uses a very simple markup language possibly inspired by Markdown, but with much more limited functionality.

On HN, only two spaces are necessary for code:

  example
And it only supports asterisks for italics, two blank lines for paragraphs, and turning URLs into links; it doesn't support any of the rest of Markdown.

Re: One in every 600 websites has .git exposed

#30
Imagine you implement every type of possible security...

Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc.

Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains all vital user-data and admin data.

Being bashed with a boulder repeatedly would probably be less painful than the torture of knowing "I did it all, but they got me with an HTTP request... because nobody thought of double-checking what our VCS is doing".

How many other glaringly obvious mistakes might be out there right now? I can only imagine.

Post reply on HN