Re: Git clone reads safe.directory differently?

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]

On 2024-07-30 at 22:49:37, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]