And what happens when Ansible checks out the Git repository for you? Or some equivalent shell script or deployment system, or some helpful developer hand-deploying something with 'git clone' on the server?
Or what about helpful developer that checked in some secrets which are visible in the repository history but not the current checkout?
Or that stupid PHP thing where 'config.php' and its MySQL passwords are world-readable, but rely on the web server interpreting it as a PHP script due to its file extension to prevent secret leaks.. not so valid when a copy of the script if available as ".git/objects/00/cf74f2066b0c72a4c4b2a24ef116f1fd23df42".
But of course, even if these weren't problems, the original point still stands: there is no guarantee .git doesn't contain secret data (such as username:password) either now, or into the future, so exposing it is a bad idea.
That's too much commentary for me to extract from a single fake link to an NXDOMAIN.
> there is no guarantee .git doesn't contain secret data (such as username:password) either now, or into the future, so exposing it is a bad idea.
The same can be said of the HTML and images, so I don't find it a useful heuristic. Note that I was disputing your claim that a username+password used to fetch a repo over http would leak into the remote's reflog.
If you perform a Git checkout on a web server e.g. as part of an Ansible script, and you embedded secrets in the repo URL (common enough, believe me), then that secret is readable per above.
FWIW this isn't some unbelievable theory or hypothetical scenario, I've seen plenty of Ansible setups like this and found domains with this exact problem in the process of writing http://pythonsweetness.tumblr.com/post/52587443706/devs-plea... a few years back
You might not remember me. I'm the poster you're responding to. How have you been? Me, I'm all right.
I was just thinking of when we first spoke… it seems like so long ago! I remember it as clearly as yesterday: you had made a partially-conherent argument that the auth creds for a git URL could leak into a remote deployment's reflog! Oh, how we laughed, and our amusement doubled in size as you fancied a implausible situation where the read-only deployment credentials could be recovered from the very same repo they allowed access to!
It was much later when we crossed paths again, but your talent for sharing inventive tales had not waned in the slightest. For this next performance, you regaled us with the simple truth that no person can be certain that their commit history will not reveal their darkest secrets, and thus should strictly eschew sharing it in a public place; but that the contents of their index was above suspicion, and could be shouted to the world without a moment's thought! Many of us stumbled to determine what byzantine process made the working directory automatically scrub itself of secrets, before finally the jape dawned on them.
I eagerly anticipate our next encounter; what fresh new hilarity will you share with us?
I hope my restatement of my understanding of your position helps make my position clear,
Or what about helpful developer that checked in some secrets which are visible in the repository history but not the current checkout?
Or that stupid PHP thing where 'config.php' and its MySQL passwords are world-readable, but rely on the web server interpreting it as a PHP script due to its file extension to prevent secret leaks.. not so valid when a copy of the script if available as ".git/objects/00/cf74f2066b0c72a4c4b2a24ef116f1fd23df42".
But of course, even if these weren't problems, the original point still stands: there is no guarantee .git doesn't contain secret data (such as username:password) either now, or into the future, so exposing it is a bad idea.
https://en.wikipedia.org/wiki/Principle_of_least_privilege