This is because git-annex-shell takes a variable number of arguments, whereas all other remote git commands take just 1 (repoPath) ( except git-lfs-authenticate which takes 2, but that has a separate special case that doesn't need gitcmd.Run()).
So doing this has weakened the security: it now means a malicious user could try to run, git-receive-pack some/repo.git ../../ 'shellinjectionattempt. git should be smart enough to just die on that situation, but what if it doesn't?
We should add some careful bounds-checking to re-enable the previous guarantee.
I just had a conflict while merging upstream with #1, and in fixing it I was able to shave off some code. But I did it by adding this:
https://github.com/neuropoly/gitea/blob/5e37296766b050f5d2b39732d4f43dd3cbe506ed/cmd/serv.go#L347
over this:
https://github.com/neuropoly/gitea/blob/f5987c24e2b561952ebf9a2485b863325c16ee48/cmd/serv.go#L308
This is because
git-annex-shelltakes a variable number of arguments, whereas all other remotegitcommands take just 1 (repoPath) ( exceptgit-lfs-authenticatewhich takes 2, but that has a separate special case that doesn't needgitcmd.Run()).So doing this has weakened the security: it now means a malicious user could try to run,
git-receive-pack some/repo.git ../../ 'shellinjectionattempt.gitshould be smart enough to just die on that situation, but what if it doesn't?We should add some careful bounds-checking to re-enable the previous guarantee.