Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder <jrnieder@gmail.com>]

Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Russ Allbery wrote:

>>> (That said, my understanding is that you don't get any meaningful
>>> integrity protection for Git from using https over http.)
>>
>> As discussed elsewhere in this thread, it depends on how much you
>> trust (a) ca-certificates, versus (b) DNS.
>
> FWIW, we're talking about integrity protection at different levels here,
> which has made this a bit confusing.  You're talking about authentication
> of the remote server so that you don't get valid commits (in the sense
> that they fit into the Git hash tree) that aren't present in the real
> remote server.  I was talking about integrity protection at the wire
> protocol level (detection of bit flips in transit, that sort of thing),
> which Git will generally do for you regardless of transport by checking
> the hashes of objects, although I'm not sure if it does a full integrity
> check on all remote packs.

I replied privately in more detail (since this is mostly off-topic for
policy), but it's probably useful to clarify a few things publicly,
too.

Indeed, you're right that Git's application-level protocol protects
against cosmic rays and single-bit flips for all objects transfered.
In protocols like git:// and the CGI-based http:// support, this is
guaranteed by the way the protocol works.  If there are any holes in
this protection (e.g. the support for non-dynamic protocols like
ftp:// and static http:// used to have such a bug) then we consider
that a serious bug and would want to know about it so it can be fixed.
Feel free to contact me at git@packages.debian.org for more details.

By integrity I was referring to something different: protection
against *malicious* manipulation of the response, by a MITM or other
hostile actor.  Git does not guarantee this unless one of the
following holds:

 A. You have learned the name of the commit or tag you are interested
    in in a reliable way out-of-band.  That is, if you check out the
    revision to be built by SHA-1 instead of by ref name, then Git
    intends to guarantee that what you check out is reliably
    determined by that SHA-1.

 B. You use signed tags or push certs to verify that you are checking
    out what you intend.  E.g. you can do this by using "git tag -v"
    to verify that the code you are checking out was (1) signed by
    someone you trust and (2) actually refers to the version you want.
    Make sure to pay attention to the output to avoid "replay" attacks
    (i.e. trying to pass off an old vulnerable tagged version of a
    package for a modern fixed version).  Or

 C. You have transport-level integrity protection, e.g. by using a
    protocol like https:// or ssh:// with proper PKI.

If people are expecting Git to guarantee that the code you fetch is
what you intended to fetch without (A), (B), or (C), then we are doing
users a dangerous misservice.  I am concerned about where that
expectation comes from and want to do what I can to improve
documentation to avoid that.  Feel free to contact me at
git@packages.debian.org to help.

> Protocol-level integrity protection doesn't help if you negotiate that
> protocol with the wrong peer, obviously, and preventing that is rather
> outside the scope of the text we're fiddling with here.

I disagree: one of the main goals of HTTPS and the basis for its
support for confidentiality and integrity is avoiding communicating
with the wrong peer.

> But this is all picking nits -- HTTPS provides both confidentiality and
> integrity protection as wire protocol features, so we can just say that
> the protocol should provide those things, regardless of the somewhat
> pedantic point about whether that integrity protection is meaningful for
> Git.

Agreed.

Thanks,
Jonathan