Re: [WIP RFC 2/5] Documentation: add Packfile URIs design doc

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Feb 21 2019, brian m. carlson wrote:

> On Tue, Feb 19, 2019 at 02:44:31PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Tue, Dec 04 2018, brian m. carlson wrote:
>> > First, I'd like to see a section (and a bit in the implementation)
>> > requiring HTTPS if the original protocol is secure (SSH or HTTPS).
>> > Allowing the server to downgrade to HTTP, even by accident, would be a
>> > security problem.
>>
>> Maybe I've misunderstood the design (I'm writing some other follow-up
>> E-Mails in this thread which might clarify things for me), but I don't
>> see why.
>>
>> We get the ref advertisement from the server. We don't need to trust the
>> CDN server or the transport layer. We just download whatever we get from
>> there, validate the packfile with SHA-1 (and in the future SHA-256). It
>> doesn't matter if the CDN transport is insecure.
>>
>> You can do this offline with git today, you don't need to trust me to
>> trust that my copy of git.git I give you on a sketchy USB stick is
>> genuine. Just unpack it, then compare the SHA-1s you get with:
>>
>>     git ls-remote https://github.com/git/git.git
>>
>> So this is a case similar to Debian's where they distribute packages
>> over http, but manifests over https: https://whydoesaptnotusehttps.com
>
> This assumes that integrity of the data is the only reason you'd want to
> use HTTPS. There's also confidentiality. Perhaps a user is downloading
> data that will help them circumvent the Great Firewall of China. A
> downgrade to HTTP could result in a long prison sentence.
>
> Furthermore, some ISPs tamper with headers to allow tracking, and some
> environments (e.g. schools and libraries) perform opportunistic
> filtering on HTTP connections to filter certain content (and a lot of
> this filtering is really simplistic).
>
> Moreover, Google is planning on using this and filters in place of Git
> LFS for large objects. I expect that if this approach becomes viable, it
> may actually grow authentication functionality, or, depending on how the
> series uses the existing code, it may already have it. In such a case,
> we should not allow authentication to go over a plaintext connection
> when the user thinks that the connection they're using is encrypted
> (since they used an SSH or HTTPS URL to clone or fetch).
>
> Downgrades from HTTPS to HTTP are generally considered CVE-worthy. We
> need to make sure that we refuse to allow a downgrade on the client
> side, even if the server ignores our request for a secure protocol.

All good points, I definitely agree we shouldn't do downgrading by
default for the reasons you've outlined, and e.g. make this an opt-in.

I'm just mindful that git's used as infrastructure in a lot of unusual
case, e.g. something like what apt's doing (after carefully weighing
http v.s. https for their use-case).

So I think providing some optional escape hatch is still a good idea.

>> > Second, this feature likely should be opt-in for SSH. One issue I've
>> > seen repeatedly is that people don't want to use HTTPS to fetch things
>> > when they're using SSH for Git. Many people in corporate environments
>> > have proxies that break HTTP for non-browser use cases[0], and using SSH
>> > is the only way that they can make a functional Git connection.
>>
>> Yeah, there should definitely be accommodations for such clients, per my
>> reading clients can always ignore the CDN and proceed with a normal
>> negotiation. Isn't that enough, or is something extra needed?
>
> I think at least a config option and a command line flag are needed to
> be able to turn CDN usage off. There needs to be an easy way for people
> in broken environments to circumvent the breakage.

Yeah, but let's try hard to make it Just Work. I.e. if in the middle of
the dialog the CDN connection is broken can we retry then, and if that
fails just continue with negotiation against the server?

As opposed to erroring by default, and the user needing to retry with
some config option...