On January 8, 2016 12:26:24 PM EST, Russ Allbery <rra@debian.org> wrote:
Scott Kitterman <debian@kitterman.com> writes:
As is currently being discussed on #debian-devel, the git:// protocol
is insecure, but is what is normally used in Vcs-git fields in Debian
packages.
For git, it would be far better to used https://, but I don't think
policy is completely clear that is OK since it says to use the
"version control system's conventional syntax". For git, that's
arguably git:// even though it's a security risk.
Please see the attached patch. Although the diff is slightly noisy,
the patch only adds one word.
I would rather add a new sentence saying that ideally the URL should
use a secure transport mechanism. Right now, with this rephrasing, it
sort of implies that if there's no encrypted transport, you shouldn't
use this field. It used to be that serving Git over HTTPS was a huge
pain and disabled a bunch of features, so some folks may just not have
bothered to ever set that up.
Sounds good to me. My proposal was an attempt at a minimal change. I
think what you're suggesting is better.
--- 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:
``Package-List``
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:
``Package-List``
Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.
On Thu, 24 Aug 2017, Sean Whitton wrote:
Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.
Attacking the integrity of the messages in transit requires active MITM attacks for all three protocols (http, https, git).
https *without* strong certificate validation has no defense against
active MITM, i.e. it does *not* protect message integrity against
attacks.
And since all of the required PKI for https to do strong certificate validation is out-of-band, we have to assume naive https use.
So, no, this is not about integrity. It is, at most, about privacy
against passive eavesdropers. If you want integrity, a lot more is
needed.
Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.
--- 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.
+
Sean Whitton <spwhitton@spwhitton.name> writes:[...]
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:
``Package-List``
Maybe I should just say:
a scheme that provides confidentiality and integrity protection
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.)
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.
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.
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.)
It would be nice to get something like chromium's certificate pinning
into curl, but that's a separate topic.
C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.
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.
Jonathan Nieder <jrnieder@gmail.com> writes:
C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.
I think it's worth being honest with ourselves here that the proper PKI
part is not really happening with the Vcs-Git field (or Vcs-Browser for
that matter) in normal usage in the context of Debian packages and random remote hosts.
The bar to the attacker is not zero when https with normal public CAs is
in use, but it's not very high.
I'm fine with including integrity protection in the protocol description anyway, but hopefully no one will think that it implies that https is providing strong authentication of the Git server here. There's non-zero authentication, but it's pretty weak.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 291 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 141:15:07 |
| Calls: | 6,611 |
| Calls today: | 1 |
| Files: | 12,159 |
| Messages: | 5,310,355 |