Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security
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
Reply to: