On 2024-07-30 at 22:49:37, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > I think if we're using --no-local (that is, if we're using upload-pack > > instead of creating symlinks), then we should not complain about the > > repository ownership. It's supposed to always be safe to clone or fetch > > from an untrusted repository, and we shouldn't complain about that. > > The safety is promised by "git fetch" when you fetch from some other > machine because the only thing you will be seeing from that > untrusted source is a bytestream that is the packfile, plus the tips > of their histories---nothing runs as yourself in this exchange other > than what you control, i.e. "git fetch", locally defined hooks and > filters defined by your configuration.. They cannot affect your > configuration file and hooks that may name extra programs that may > run as you while fetching or cloning. > > When you are using "--no-local" on the same machine, I do not think > there is any guarantee that "upload-pack" side is safe. And that is > where the safe.directory thing needs to kick in. > > Stepping into an untrusted repository and running git operations > opens up the user the Git process runs as to attacks by the > untrusted repository, i.e. you may invoke hooks on the upload-pack > side, defined in the source repository that is controlled by others, > and that is where the safe.directory thing kicks in. You need to > declare that you trust that source repository. I don't believe git-upload-pack invokes hooks. At least, I don't see any documented to do so, and I'm not aware of any from my experience hosting repositories. Certainly git-receive-pack does so, which I can understand as a problem, but upload-pack should not. And the manual page does say this: Most Git commands should not be run in an untrusted `.git` directory (see the section `SECURITY` in git(1)). `upload-pack` tries to avoid any dangerous configuration options or hooks from the repository it's serving, making it safe to clone an untrusted directory and run commands on the resulting clone. The git(1) manual page also says this: If you have an untrusted `.git` directory, you should first clone it with `git clone --no-local` to obtain a clean copy. Git does restrict the set of options and hooks that will be run by `upload-pack`, which handles the server side of a clone or fetch, but beware that the surface area for attack against `upload-pack` is large, so this does carry some risk. The safest thing is to serve the repository as an unprivileged user (either via git-daemon(1), ssh, or using other tools to change user ids). See the discussion in the `SECURITY` section of git-upload-pack(1). I think that has been traditionally the policy that we've had here, and given that we document that it is safe to do so, I think it should be fine. This documentation apparently came from Peff, who I think should be reasonably well informed on such matters. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
