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

[Russ Allbery <rra@debian.org>]

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.

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.

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.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>