Jonathan Nieder <jrnie...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>