[Uwe Kleine-König] Bug#871632: gitolite3: include % by default as allowed char in refs

[David Bremner]

A Debian user makes the following request [0]. At least the part about
allowing % seems sensible to me. I'm not sure about ':' ; it does occur
in filenames on my systems (mainly in Maildirs, fwiw).

Package: gitolite3
Version: 3.6.1-2+deb8u2
Severity: wishlist

Hello,

Following DEP14[1] to name my tags for debian packaging I use % in
tagnames. When I then try to push such a tag to a gitolite instance I
get:

remote: FATAL: invalid characters in ref or filename: 'refs/tags/debian/1%1.6.22-1'

The reason is that $REF_OR_FILENAME_PATT doesn't allow % in a ref name.
This can be easily fixed by setting this variable in
~gitolite/.gitolite.rc like:

$REF_OR_FILENAME_PATT = qr(^[0-9a-zA-Z][-0-9a-zA-Z._\@/+ :,%]*$);

. But I wonder why gitolite is restrictive here and wish that % was be
allowed by default. (Side note: git doesn't allow : in refnames, so
there more changes to REF_OR_FILENAME_PATT might be sensible.)

Best regards
Uwe

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871632
[1] http://dep.debian.net/deps/dep14/

[Sitaram Chamarty]

People: please read and weigh in if you have an opinion!

On Sun, Aug 13, 2017 at 12:41:54PM -0400, David Bremner wrote:
>
> A Debian user makes the following request [0]. At least the part about
> allowing % seems sensible to me. I'm not sure about ':' ; it does occur
> in filenames on my systems (mainly in Maildirs, fwiw).

Let's deal with the simpler one first: I actually think colon is
safe -- neither variable interpolation nor code execution seem
to be possible with it. I have no idea why git does not allow
it in refs; if someone knows, please let us know.

As for the "%", I'm going to punt on this, in the sense that I'd
like you all to weigh in on what they think.

When I originally set up those restrictions, I made them as
paranoid as possible, while making it possible for any admin to
locally relax those restrictions.

Since that mechanism exists (as the bug report below also
notes), any *shipped* changes to these patterns must be
unquestionably safe.

Is "%" unquestionably safe? I don't know. It seems safe enough
-- I only know it is used in various format specifiers. Can
someone find a creative way to use that against a server?

Just because *I* can't think of some way to use it in an attack
does not mean someone else cannot.

(If you've seen the recent git/hg/svn/etc vuln that is basically
caused by allowing a leading "-" in an ssh URL, you'll see how
simple in hindsight something is, even if we never thought of it
in advance. Almost every VCS that allows ssh access is
apparently affected by this!)

regards
sitaram

>
> Package: gitolite3
> Version: 3.6.1-2+deb8u2
> Severity: wishlist
>
> Hello,
>
> Following DEP14[1] to name my tags for debian packaging I use % in
> tagnames. When I then try to push such a tag to a gitolite instance I
> get:
>
> remote: FATAL: invalid characters in ref or filename: 'refs/tags/debian/1%1.6.22-1'
>
> The reason is that $REF_OR_FILENAME_PATT doesn't allow % in a ref name.
> This can be easily fixed by setting this variable in
> ~gitolite/.gitolite.rc like:
>
> $REF_OR_FILENAME_PATT = qr(^[0-9a-zA-Z][-0-9a-zA-Z._\@/+ :,%]*$);
>
> . But I wonder why gitolite is restrictive here and wish that % was be
> allowed by default. (Side note: git doesn't allow : in refnames, so
> there more changes to REF_OR_FILENAME_PATT might be sensible.)
>
> Best regards
> Uwe
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871632
> [1] http://dep.debian.net/deps/dep14/
>

> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David Bremner]

Sitaram Chamarty <sita...@gmail.com> writes:


> People: please read and weigh in if you have an opinion!
>
> On Sun, Aug 13, 2017 at 12:41:54PM -0400, David Bremner wrote:
>>
>> A Debian user makes the following request [0]. At least the part about
>> allowing % seems sensible to me. I'm not sure about ':' ; it does occur
>> in filenames on my systems (mainly in Maildirs, fwiw).
>
> Let's deal with the simpler one first: I actually think colon is
> safe -- neither variable interpolation nor code execution seem
> to be possible with it. I have no idea why git does not allow
> it in refs; if someone knows, please let us know.

According to git-check-ref-format(1), this is so parsing with shell scripts
is easy.

> Is "%" unquestionably safe? I don't know. It seems safe enough
> -- I only know it is used in various format specifiers. Can
> someone find a creative way to use that against a server?
>
> Just because *I* can't think of some way to use it in an attack
> does not mean someone else cannot.
>
> (If you've seen the recent git/hg/svn/etc vuln that is basically
> caused by allowing a leading "-" in an ssh URL, you'll see how
> simple in hindsight something is, even if we never thought of it
> in advance. Almost every VCS that allows ssh access is
> apparently affected by this!)

I'm certainly curious what people have to say about '%'. One thing
someone mentioned on IRC to me is that '@' triggers interpolation
in perl strings, so that might also be something to think about.

d

[Sitaram Chamarty]

On Tue, Aug 15, 2017 at 11:21:57AM -0300, David Bremner wrote:
> Sitaram Chamarty <sita...@gmail.com> writes:
>
>
> > People: please read and weigh in if you have an opinion!
> >
> > On Sun, Aug 13, 2017 at 12:41:54PM -0400, David Bremner wrote:
> >>
> >> A Debian user makes the following request [0]. At least the part about
> >> allowing % seems sensible to me. I'm not sure about ':' ; it does occur
> >> in filenames on my systems (mainly in Maildirs, fwiw).
> >
> > Let's deal with the simpler one first: I actually think colon is
> > safe -- neither variable interpolation nor code execution seem
> > to be possible with it. I have no idea why git does not allow
> > it in refs; if someone knows, please let us know.
>
> According to git-check-ref-format(1), this is so parsing with shell scripts
> is easy.

Oh I see. Well anyway, they used colon as the separator for
"src:dest" in a refspec, and for "ref:path" in git show type
commands, so I'm pretty sure it's not a security related reason.

> > Is "%" unquestionably safe? I don't know. It seems safe enough
> > -- I only know it is used in various format specifiers. Can
> > someone find a creative way to use that against a server?
> >
> > Just because *I* can't think of some way to use it in an attack
> > does not mean someone else cannot.
> >
> > (If you've seen the recent git/hg/svn/etc vuln that is basically
> > caused by allowing a leading "-" in an ssh URL, you'll see how
> > simple in hindsight something is, even if we never thought of it
> > in advance. Almost every VCS that allows ssh access is
> > apparently affected by this!)
>
> I'm certainly curious what people have to say about '%'. One thing
> someone mentioned on IRC to me is that '@' triggers interpolation
> in perl strings, so that might also be something to think about.

yes it does but perl interpolation does not seem to work as
"unexpectedly" (sorry, I am not finding time to think up a
better way of putting this).

regards
sitaram