[tangotaylor]

Beware of using this to publish static sites: you can accidentally expose your .git directory to the public internet.

I got pwned this way before (by a pentester fortunately). I had to configure Apache to block the .git directory.

[jonhohle]

Instead of excluding non-public directories, I like to make an explicit `public` directory (or `doc`, `doc-root`, whatever you want to call it). Then configure your server to point to that subdirectory and don’t worry about the repo.

I usually throw `etc` and `log` directories at the top level as well and out my server config in etc, and have a gitignite rule to ignore everything in logs, but it’s there and ready for painless deployment.

Since the web root is already a sub directory, more sensitive things can go into the same repo without worrying about exposing them.

[wizzwizz4]

Storing volatile data (e.g. logs) in the git-managed directory is an excellent way to lose all your data. https://fediverse.blog/~/Prismo/on-prismo-data-loss

[cesnja]

You can still get hit by a path traversal exploit. The safest option is to only have the public files on the server.

[jonhohle]

A path traversal is different from putting private files in a public directory. For a simple static site there will always be certs, /etc, and other things outside of the document root that shouldn’t be served.

[kragen]

I expose my .git directory to the public internet on purpose. If I don't, how will anyone else clone the repo?

[CGamesPlay]

But what, exactly, was pwned? Did you have secrets in the git repo?

[tangotaylor]

No secrets like auth credentials or tokens but:

- Deleted files and development artifacts that were never meant to go public.

- My name and email address.

- Cringy commit messages.

I assumed these commits and their metadata would be private.

It was embarrassing. I was in high school, I was a noob.

[tasuki]

I expose the .git directories on my web server and never considered it a problem. I also expose them on GitHub and didn't consider that a problem either...

[giobox]

Super common failure is accidental commit of a secret key. People suck at actually deleting something from git history. Had one colleague leak a Digital Ocean key this way with an accidental env file commit. He reverted, but the key is of course still present in the project history.

The speed at which an accidentally committed and reverted key is compromised and used to say launch a fleet of stolen VPSes on a github public repo nowadays is incredible. Fortunately most of the time your provider will cancel the charges...

This has always been the roughest part of git for me, the process to remove accidentally committed sensitive content. Sure we should all strive not to commit stupid things in the first place, and of course we have tools like gitignore, but we are all only human.

> https://docs.github.com/en/authentication/keeping-your-accou...

"Sensitive data can be removed from the history of a repository if you can carefully coordinate with everyone who has cloned it and you are willing to manage the side effects."