This could be even worse. I assume git does a checkout after cloning a repository, this hook could be triggered right after a clone without your ability to review it.
Edit: I tried, and git refuses to checkout the file initially :
$ git clone bad-repo.got
Cloning into'bad-repo'...
done.
error: invalid path '.git/hooks/post-checkout'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked outwith'git status'and retry with'git restore --source=HEAD :/'
So I assume that you’re safe as long as you ALWAYS clone repositories with git, and don’t retrieve the work tree from someone else (like the author was asked to).
Nothing within git (the repository format) prevents you from commiting a hook though, so it’s up to the frontend to secure against it.
I also tried with got, and it refuses to checkout the file as well. No idea about jj or other git frontends.
It’s difficult for the format to do anything about this. You’d need to come up with a way of encoding a path which had no representation for paths starting with .git/.
This attack path has been known about for a long time. And git has refused to check out files at paths starting with ./git for as long as I remember.
There was a bug on windows years ago due to its case insensitive FS.
Generally treat any .git directory that git itself has not created as a live grenade.
This could be even worse. I assume git does a checkout after cloning a repository, this hook could be triggered right after a clone without your ability to review it.
Edit: I tried, and git refuses to checkout the file initially :
$ git clone bad-repo.got Cloning into 'bad-repo'... done. error: invalid path '.git/hooks/post-checkout' fatal: unable to checkout working tree warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry with 'git restore --source=HEAD :/'So I assume that you’re safe as long as you ALWAYS clone repositories with
git, and don’t retrieve the work tree from someone else (like the author was asked to).Nothing within git (the repository format) prevents you from commiting a hook though, so it’s up to the frontend to secure against it.
I also tried with
got, and it refuses to checkout the file as well. No idea aboutjjor other git frontends.score 2 · canonical
It’s difficult for the format to do anything about this. You’d need to come up with a way of encoding a path which had no representation for paths starting with
.git/.This attack path has been known about for a long time. And git has refused to check out files at paths starting with
./gitfor as long as I remember.There was a bug on windows years ago due to its case insensitive FS.
Generally treat any .git directory that git itself has not created as a live grenade.
score 1 · canonical