Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> I hesitate to suggest this, but: we have a similar distinction already
> for protocol selection, where GIT_PROTOCOL_FROM_USER tells us whether
> the URL came directly from the user, or if we were directed there as
> part of an untrusted automated process (like a .gitmodules file).
>
> We use that to disallow file:// from .gitmodules without breaking "git
> clone file://" on the command line.
>
> So we _could_ use that as a signal here, to suggest that servers you
> feed on the command line (including remotes you've defined) are more
> trusted than ones that you may have been redirected to from a possibly
> malicious .gitmodules file.
>
> But I say "hesitate" because:
>
>   1. This is a convoluted scheme making heuristic assumptions about
>      trust. It was a not-so-bad way of compromising on the file://
>      thing, but it may not be worth the complications here.
>
>   2. The trust boundaries aren't quite the same anyway. If I feed
>      "https://evil.example.com" to Git manually, I can verify that
>      "https" is the URL and that is OK to use the HTTP protocol. But it
>      doesn't say anything about whether I trust example.com to write to
>      my terminal.
>
> So maybe a dumb direction, but just thinking out loud.

Yeah, I think #2 makes it unworkable for this purpose.  When
somebody you met recently at a party and you not yet know how much
to trust told you "You may be interested in this nifty add-on I have
in my repository at https://example.com/nifty.git", you may want to
clone it only to peek at it first without trusting it.  So automated
or manually fed from the command line, I'd say the destination where
"git clone" goes is much less trusted than the cloned repositories
you keep (presumably after inspecting and interacting with its
contents enough).