UNSAFE_PATT

[Ralf Hemmecke]

Just a note for people that fall into this trap.

I used to follow

http://stackoverflow.com/questions/804601/git-post-receive-email-hook-including-diff-patches

In gitolite2 I had

repo somerepo
config hooks.showrev = "git show -C %s; echo"
...

in my gitolite-admin/conf/gitolite.conf.

In gitolite3 the UNSAFE_PATT variable rules that out.
During migration I got

gitolite push -f
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
remote: FATAL: bad value 'git show -C %s; echo'
To /home/hemmecke/repositories/gitolite-admin.git
974b8c4..8a55062 master -> master

Sitaram, just for curiosity, why do you consider ';' to be an unsafe
pattern? In fact,

repo somerepo
config hooks.showrev = "/bin/rm -rf /home/hemmecke"
...

passes the $UNSAFE_PATT and my little extra "; echo" does not.

Looks like this is a bit over securified and somewhat useless. Am I wrong?

Ralf

[Sitaram Chamarty]

On Wed, Oct 3, 2012 at 2:55 AM, Ralf Hemmecke <hemm...@gmail.com> wrote:

> config hooks.showrev = "/bin/rm -rf /home/hemmecke"
> ...
>
> passes the $UNSAFE_PATT and my little extra "; echo" does not.
>
> Looks like this is a bit over securified and somewhat useless. Am I wrong?

depends on how that string is used. If it's ever executed directly as
a command, both are bad. But under certain types of quoting the
second form may end up executing only the part after the semicolon.
Think "bobby tables".

You can change UNSAFE_PATT however you want, in the rc file. That
will override the default.

[Dan Carpenter]

I feel partly responsible. Here is how UNSAFE_PATT came around.
https://groups.google.com/forum/?fromgroups=#!topic/gitolite/jcUkIFKxbQ8

regards,
dan carpenter

[Ralf Hemmecke]

On 10/03/2012 03:28 AM, Sitaram Chamarty wrote:
> On Wed, Oct 3, 2012 at 2:55 AM, Ralf Hemmecke <hemm...@gmail.com> wrote:
>
>> config hooks.showrev = "/bin/rm -rf /home/hemmecke"
>> ...
>>
>> passes the $UNSAFE_PATT and my little extra "; echo" does not.
>>
>> Looks like this is a bit over securified and somewhat useless. Am I wrong?
>
> depends on how that string is used. If it's ever executed directly as
> a command, both are bad.

Do I understand correctly that you consider

config hooks.showrev = "git show -C %s; echo"

bad? Well, it's not really a gitolite issue, but can you tell me why
it's bad? Or is it just because "showrev" is executed on the server?

> But under certain types of quoting the
> second form may end up executing only the part after the semicolon.
> Think "bobby tables".

Oh, of course, I understand that I shouldn't allow hooks.showrev, but
I'm the only admin of this gitolite instance and I have shell access to
the server, so gitolite protects me against myself. ;-)

> You can change UNSAFE_PATT however you want, in the rc file. That
> will override the default.

That's probably the easiest solution for my setup. But is my use case so
uncommon? I.e. a user that has a login on some server (no root access)
and installs gitolite in his home dir on the server and then selectively
gives read or write access to collaborators. Think scientists who
collaborate on an article.

I actually like gitolite a lot, because with a little knowledge of this
ssh stuff and the fact that installation is pretty easy, I don't have to
ask my system administrator to setup a gitolite infrastructure for me.
Involving a sysadmin sometimes makes easy things take ages.

So, a little documentation of UNSAFE_PATT would be welcome in the rc file.

Anyway, thank you, Sitaram, for gitolite and also for the kind and
prompt support you give.

Ralf

[Sitaram Chamarty]

On Wed, Oct 3, 2012 at 1:04 PM, Ralf Hemmecke <hemm...@gmail.com> wrote:
> On 10/03/2012 03:28 AM, Sitaram Chamarty wrote:
>> On Wed, Oct 3, 2012 at 2:55 AM, Ralf Hemmecke <hemm...@gmail.com> wrote:
>>
>>> config hooks.showrev = "/bin/rm -rf /home/hemmecke"
>>> ...
>>>
>>> passes the $UNSAFE_PATT and my little extra "; echo" does not.
>>>
>>> Looks like this is a bit over securified and somewhat useless. Am I wrong?
>>
>> depends on how that string is used. If it's ever executed directly as
>> a command, both are bad.
>
> Do I understand correctly that you consider
>
> config hooks.showrev = "git show -C %s; echo"
>
> bad? Well, it's not really a gitolite issue, but can you tell me why
> it's bad? Or is it just because "showrev" is executed on the server?

Yes I do, but I can't explain it. See the thing is, proving something
harmless is hard to do. And since there exists a work-around, I'd
prefer to leave it like that.

> That's probably the easiest solution for my setup. But is my use case so
> uncommon? I.e. a user that has a login on some server (no root access)

Well I'm not sure how many users I have for v3 yet but only a couple
of these kinds of questions have come up so far.

Look at it this way: your needs were simple enough to be satisfied by
an inline shell command. Perhaps other's needs are complex enough to
be wrapped in a script anyway so this becomes moot.

One thing I am going to maintain is the distinction between "able to
push to the admin repo" and "able to run arbitrary commands on the
server". You will have to break that distinction yourself. It's not
that hard to break, but gitolite by default won't let one escalate to
the other and I'll try to make sure you're *aware* you're breaking
this.

> and installs gitolite in his home dir on the server and then selectively
> gives read or write access to collaborators. Think scientists who
> collaborate on an article.
>
> I actually like gitolite a lot, because with a little knowledge of this
> ssh stuff and the fact that installation is pretty easy, I don't have to
> ask my system administrator to setup a gitolite infrastructure for me.
> Involving a sysadmin sometimes makes easy things take ages.
>
> So, a little documentation of UNSAFE_PATT would be welcome in the rc file.

In the same spirit (i.e., "make sure you aware you're breaking this"),
I tend to think *not* documenting this is better. It forces people to
ask, and my reply in turn forces them to think, I hope, about the
implications (to whatever extent that is meaningful). Putting it in
the docs would lead to people just giving it something that will never
match and be done.

But if you feel very strongly that it should be in the docs (or,
better still, if someone else chips in and says so), then I will.

> Anyway, thank you, Sitaram, for gitolite and also for the kind and
> prompt support you give.

And that's an important part of the previous answer. Within
reasonable limits, I will always reply, and I won't ignore emails. So
-- despite my craze for documentation -- it may be acceptable for some
things to stay undocumented.

sitaram

[Sitaram Chamarty]

On Wednesday, October 3, 2012 2:55:16 AM UTC+5:30, hemmecke wrote:

> In gitolite2 I had

> repo somerepo
> config hooks.showrev = "git show -C %s; echo"

(replying from google's interface sucks so I'm cutting out most of the original email).

Long story short: this no longer works in v3, and the recommendation has been to modify UNSAFE_PATT and place the modified assignment in the rc file.

Someone else asked about this on irc, and I pointed him to this link. Then I got to thinking...

Anyway, take a look at the brand new "compensating for UNSAFE_PATT" section in http://sitaramc.github.com/gitolite/git-config.html.

[Ralf Hemmecke]

On 01/08/2013 11:47 AM, Sitaram Chamarty wrote:
>> In gitolite2 I had
>
>> repo somerepo config hooks.showrev = "git show -C %s; echo"

> Anyway, take a look at the brand new "compensating for UNSAFE_PATT"
> section in http://sitaramc.github.com/gitolite/git-config.html.

Well, this doesn't give full flexibility to the gitolite-admin, but I
think your new idea looks cleaner. I somehow like it. Before, I felt
that UNSAFE_PATT was misused for something like this showrev option.

Maybe it it even makes sense to promote it more prominently that for
core gitolite there are 4 roles

sysadmin -- has shell access to the server and installs gitolite
gitolite-admin -- has RW acess to the gitolite-admin repo
user -- someoen with access to one of the managed git repos
nonuser -- no pubkey provided, no access to anything

Ralf

[Sitaram Chamarty]

On Wed, Jan 9, 2013 at 3:42 AM, Ralf Hemmecke <ra...@hemmecke.org> wrote:

> Maybe it it even makes sense to promote it more prominently that for
> core gitolite there are 4 roles
>
> sysadmin -- has shell access to the server and installs gitolite
> gitolite-admin -- has RW acess to the gitolite-admin repo
> user -- someoen with access to one of the managed git repos
> nonuser -- no pubkey provided, no access to anything

Good idea -- I never explicitly stated the distinction between the
first two in that list (though the last 3 are kind of obvious). Which
document would be a good place for it, do you think?

[Ralf Hemmecke]

Yes, I thought a bit before adding user and nonuser, but in fact, it
*is* information.

For example, it was not totally obvious to me that in order to give
someone read access to a repository, I have to get his/her public key
and enter it into keydir. Well, this was clear. But what if I wanted to
give public read access to the world?

Well, there would be the option of gitweb, but that is not
gitolite-core. Or I could distribute a private key for public read
access (probably not the best idea).

Your first sentence says:
==============
Gitolite allows you to setup git hosting on a central server, with
fine-grained access control and many more powerful features.
==============
from which one might guess that one can also setup public read access.

The 4 roles above would make it more obvious where the use cases for
gitolite are.

Before I started this mail, I was unsure about the place, but now I
think, right at http://sitaramc.github.com/gitolite/ would be a good
place. Either you put it right at the top or into the section "what is
gitolite".

Ralf

[Sitaram Chamarty]

On Wed, Jan 9, 2013 at 6:26 AM, Ralf Hemmecke <ra...@hemmecke.org> wrote:
> On 01/09/2013 12:21 AM, Sitaram Chamarty wrote:
>> On Wed, Jan 9, 2013 at 3:42 AM, Ralf Hemmecke <ra...@hemmecke.org> wrote:
>>
>>> Maybe it it even makes sense to promote it more prominently that for
>>> core gitolite there are 4 roles
>>>
>>> sysadmin -- has shell access to the server and installs gitolite
>>> gitolite-admin -- has RW acess to the gitolite-admin repo
>>> user -- someoen with access to one of the managed git repos
>>> nonuser -- no pubkey provided, no access to anything
>>
>> Good idea -- I never explicitly stated the distinction between the
>> first two in that list (though the last 3 are kind of obvious). Which
>> document would be a good place for it, do you think?
>
> Yes, I thought a bit before adding user and nonuser, but in fact, it
> *is* information.
>
> For example, it was not totally obvious to me that in order to give
> someone read access to a repository, I have to get his/her public key
> and enter it into keydir. Well, this was clear. But what if I wanted to
> give public read access to the world?

Oh come on -- this is all ssh based; I am not going to be writing ssh
basic documentation (well, not any more than I already have, heh!)

That question is only remotely valid for someone using http mode,
where the userid specified as HTTP_ANON_USER in the rc file is used as
the "default" user. (And which, I freely admit, is not in the docs
but it's a very small point).

> Well, there would be the option of gitweb, but that is not
> gitolite-core. Or I could distribute a private key for public read
> access (probably not the best idea).
>
> Your first sentence says:
> ==============
> Gitolite allows you to setup git hosting on a central server, with
> fine-grained access control and many more powerful features.
> ==============
> from which one might guess that one can also setup public read access.

And you would not read any further? The "What is gitolite" section a
bit further down says "Authentication is most commonly done using
sshd...".

I should not need to mention that sshd does not allow random public
access -- if someone does not know that, he should not be installing
gitolite or even thinking about it. As I say in the ssh part of the
documentation, you're a system admin, like it or not.

> The 4 roles above would make it more obvious where the use cases for
> gitolite are.
>
> Before I started this mail, I was unsure about the place, but now I
> think, right at http://sitaramc.github.com/gitolite/ would be a good
> place. Either you put it right at the top or into the section "what is
> gitolite".

but you have just kinda-sorta-vaguely shown/hinted that people won't
read that far and opt instead to assumed based on the first line ;-)

I think the right place is closer to the first place where the
gitolite-admin repo is mentioned, because at the "what is gitolite"
stage you haven't got that insight yet, and you need that to be able
to say distinguish 1 and 2.

[Jonas Wagner]

Hi

This is a reply for a fairly old thread. I found it (and the new documentation at http://gitolite.com/gitolite/git-config.html#compensating-for-unsafe_patt ) very helpful.

For me, the UNSAFE_PATT bit me when I tried to set the following:

config hooks.mailinglist = "Jonas Wagner <my.e...@address.com>"

I solved it by removing <> from UNSAFE_PATT. The SAFE_CONFIG solution seemed not applicable, because each repo has a different mailing list and it would be unwieldy to specify them all.

Since this is something that changed with v3, would it make sense to mention it in the migration documentation?

Best,
Jonas

[Sitaram Chamarty]

On 02/27/2014 03:56 PM, Jonas Wagner wrote:
> Hi
>
> This is a reply for a fairly old thread. I found it (and the new
> documentation at
> http://gitolite.com/gitolite/git-config.html#compensating-for-unsafe_patt
> ) very helpful.
>
> For me, the UNSAFE_PATT bit me when I tried to set the following:
>
> config hooks.mailinglist = "Jonas Wagner <my.e...@address.com>"
>
> I solved it by removing <> from UNSAFE_PATT. The SAFE_CONFIG solution
> seemed not applicable, because each repo has a different mailing list
> and it would be unwieldy to specify them all.

Hmm; I need to fix *that* documentation first, because this certainly works:

# in the rc file
SAFE_CONFIG => {
LT => '<',
GT => '>',
},

# in gitolite.conf
config hooks.mailinglist = "Jonas Wagner %LTmy....@address.com%GT"

but it's so weird looking maybe I shouldn't bother :-)

> Since this is something that changed with v3, would it make sense to
> mention it in the migration documentation?

Agreed. I'll add it to the low-impact (or maybe medium-impact) section.