Bug#867699: fatal: transport 'ext' not allowed

[Ian Jackson]

Jakub Wilk writes ("Re: Bug#867699: fatal: transport 'ext' not allowed"):
> * Ian Jackson <ijack...@chiark.greenend.org.uk>, 2017-07-08, 18:30:
> >if this change was done for security reasons, why has it not been done 
> >in stretch ?
> 
> This change was introduced in this commit:
> https://github.com/git/git/commit/f1762d772e9b415a3163abf5f217fc3b71a3b40e
> 
> The commit message doesn't mention any security implications. In fact, 
> it doesn't even explicitly say that it changes the default behavior. :-/
> 
> I suspect it was meant to be hardening, rather than a security fix.

Right.  Do you think we should backport this to stretch ?  I would be
inclined to say "no" because of the compatibility risk, but it seems
arguable to me.

IDK who else might be using ext:.  As for dgit, which is where I
noticed this, the breakage is in the dgit _test suite_.  dgit itself
does not use ext:.  I have no idea whether that's usefully indicative
of other callers' situations.

> See #840014 for a bug that was mitigated thanks to this change.
> Other security bugs that could be exploited via git-remote-ext:
> https://github.com/sociomantic-tsunami/git-hub/issues/197
> https://github.com/seveas/git-spindle/issues/154

Right.  This is why I'm not asking for this change to be reverted.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#867699: fatal: transport 'ext' not allowed

[Jakub Wilk]

* Ian Jackson , 2017-07-08, 18:30:
if this change was done for security reasons, why has it not been done 
in stretch ?


This change was introduced in this commit:
https://github.com/git/git/commit/f1762d772e9b415a3163abf5f217fc3b71a3b40e

The commit message doesn't mention any security implications. In fact, 
it doesn't even explicitly say that it changes the default behavior. :-/


I suspect it was meant to be hardening, rather than a security fix.

See #840014 for a bug that was mitigated thanks to this change.
Other security bugs that could be exploited via git-remote-ext:
https://github.com/sociomantic-tsunami/git-hub/issues/197
https://github.com/seveas/git-spindle/issues/154

--
Jakub Wilk

Bug#867699: fatal: transport 'ext' not allowed

[Ian Jackson]

Package: git
Version: 1:2.13.2-3

The dgit test suite has started failing with this message.  I looked
in various places to try to find out why.

Amongst my attempts where
  man git-remote-ext
  man git-push
  man git-pull
  dpkg -L git-man | xargs zegrep '\bext\b' 2>/dev/null |less -S
  dpkg -L git-man | xargs zegrep '\btransport\b' 2>/dev/null |less -S

I dug into the git source code to find out what was going on.  I found
that the source code talks about protocols, not transports.  Hence I
found the real answer in:
  man git-config |less +/'protocol.*allow'

Please could, at the very least, git-remote-ext document this
behaviour: ie specifically, git-remote-ext(1) should say that the
feature needs to be explicitly enabled.

Secondly, I see from the source code that one can set
GIT_ALLOW_PROTOCOL to a :-separated list.  Could this please also be
documented ?

Thirdly: please could incompatible changes be documented somewhere
more obvious - how about NEWS.Debian.gz ?

Fourthly: if this change was done for security reasons, why has it not
been done in stretch ?

Thanks for your attention,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.