4 ms·

This is too much of blanket statement. As long as there's nothing secret in the repository, serving up .git is perfectly fine. Both http://codemirror.net http:/

by marijn 13y ago

This is too much of blanket statement. As long as there's nothing secret in the repository, serving up .git is perfectly fine. Both http://codemirror.net http://codemirror.net and http://ternjs.net http://ternjs.net (projects by me) have websites that are simply checkouts of the projects' repositories. Which were already public.

_wmd 13y ago
This is pretty much a blanket statement for any project of reasonable size (or even with just a sole clueless developer). But don't take my word for it, check the evidence first hand by poking around the list for yourself :) The solution is so effortless that it seems indefensible to serve .git, when the risk of doing so is a fleeting moment of forgetfulness leading to your site and databases getting pwned. Kind of like /etc/passwd being "public" so long as nobody puts their password in their GECOS field. Why take the risk.
- apendleton 13y ago
  No, it really isn't a blanket statement. Almost all of my organization's web properties are public github repos (yay, non-profit organizations!). I doubt any of our properties serve .git, but that's just for technical architecture reasons (they're mostly Django apps), and there's literally nothing in the .git directories that isn't already available for free.
- marijn 13y ago
  The repository is already public. It can't get any more public by being exposed over the website.
- tingletech 13y ago
  Back in the 90s I found I could get to /etc/passwd of a campus machine via anonymous ftp. I got all worried and I reported to the sysadmin, and they said anyone of the thousands of students who could log into the machine could read /etc/passwd anyway, and it was not a big deal because the passwords were in /etc/shadow and the anonymous ftp user could not read that file. This was back before ssh, and I think I expressed a concern about people knowing who had accounts on the machine, but you could tell if someone had an account via finger. Still seems like a bad idea to me. But if .git is from a public repo on github already I don't see the issue.
  - _wmd 13y ago
    So long as the initial checkout wasn't made via https://user:password@github.com/your/repo/ https://user:password@github.com/your/repo/ URL it might not be an issue. But git doesn't warn in this case, happily writes the password you provide in plaintext to your web root, and you may never notice anything is wrong until much later. If it's not that, then perhaps it's the rude comment made about a coworker in COMMIT_EDITMSG that you abandoned before committing.. Even if neither of these were the case, the general principle of unnecessarily exporting chunks of internal state is asking for trouble somewhere, even if you can't think of a good reason why it would bite today.

by marijn 13y ago

_wmd 13y ago

This is pretty much a blanket statement for any project of reasonable size (or even with just a sole clueless developer). But don't take my word for it, check the evidence first hand by poking around the list for yourself :) The solution is so effortless that it seems indefensible to serve .git, when the risk of doing so is a fleeting moment of forgetfulness leading to your site and databases getting pwned. Kind of like /etc/passwd being "public" so long as nobody puts their password in their GECOS field. Why take the risk.

apendleton 13y ago
No, it really isn't a blanket statement. Almost all of my organization's web properties are public github repos (yay, non-profit organizations!). I doubt any of our properties serve .git, but that's just for technical architecture reasons (they're mostly Django apps), and there's literally nothing in the .git directories that isn't already available for free.
marijn 13y ago
The repository is already public. It can't get any more public by being exposed over the website.
tingletech 13y ago
Back in the 90s I found I could get to /etc/passwd of a campus machine via anonymous ftp. I got all worried and I reported to the sysadmin, and they said anyone of the thousands of students who could log into the machine could read /etc/passwd anyway, and it was not a big deal because the passwords were in /etc/shadow and the anonymous ftp user could not read that file. This was back before ssh, and I think I expressed a concern about people knowing who had accounts on the machine, but you could tell if someone had an account via finger. Still seems like a bad idea to me. But if .git is from a public repo on github already I don't see the issue.
- _wmd 13y ago
  So long as the initial checkout wasn't made via https://user:password@github.com/your/repo/ https://user:password@github.com/your/repo/ URL it might not be an issue. But git doesn't warn in this case, happily writes the password you provide in plaintext to your web root, and you may never notice anything is wrong until much later. If it's not that, then perhaps it's the rude comment made about a coworker in COMMIT_EDITMSG that you abandoned before committing.. Even if neither of these were the case, the general principle of unnecessarily exporting chunks of internal state is asking for trouble somewhere, even if you can't think of a good reason why it would bite today.