Jonathan Nieder wrote: > Russ Allbery wrote: >>> On Wed, Aug 23 2017, Russ Allbery wrote:
>>>> --- a/policy/ch-controlfields.rst >>>> +++ b/policy/ch-controlfields.rst >>>> @@ -962,6 +962,10 @@ repository where the Debian source package is >>>> developed. >>>> >>>> More than one different VCS may be specified for the same package. >>>> >>>> +For both fields, any URLs given should use a scheme that provides >>>> +confidentiality (``https``, for example, rather than ``http`` or ``git``) >>>> +if the VCS repository supports it. >>>> + >>>> .. _s-f-Package-List: [...] >> Maybe I should just say: >> >> a scheme that provides confidentiality and integrity protection > > Seconded. > >> I think I was over-thinking it. >> >> (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. Correction: even if you trust DNS, you also have to trust IP infrastructure to ensure your traffic goes to the intended destination without a MITM modifying it. That means that even with trustworthy DNS (e.g. using dnssec), if your ISP is compromised then you have neither meaningful confidentiality protection nor meaningful integrity protection over http, beyond what your version control system provides at the application level. A good VPN can improve on that, depending on the destination of your traffic. But given all the above, I have to say, https really does seem like a meaningful improvement. All that said, the other points still apply: > The ideal is to use signed tags and check them. (Or even better, to > work with git upstream to get push certs distributed properly and > check those.) These two approaches can protect integrity but do not help with confidentiality. > It would be nice to get something like chromium's certificate pinning > into curl, but that's a separate topic. Something like this (or a revamping of ca-certificates) is needed for confidentiality in the presence of a MITM. And I agree with you that policy doesn't need to get into these details. Thanks, Jonathan
