thoughts on a possible "pre-upload" hook

thoughts on a possible "pre-upload" hook

[Sitaram Chamarty]

Hello,

As git is used more and more in corporate-type environments, at some
point it becomes convenient to have *branches* (or more accurately,
refs) that are not readable.  The simplest way to do this (from git's
point of view) is to allow a "pre-upload" hook, rather like the
"pre-receive" hook or "update" hook.

I don't know the upload pack protocol enough to know whether this is a
stupid idea or not; please tell me if so :-)  But things that were
seemingly "impossible" in the early days are being talked about now
and even being implemented so I felt brave enough to ask.

I'm afraid my C programming days are long gone, but if anything can be
done in shell or perl, with a little git.guidance, I'll do whatever I
can.

-- 
Sitaram

Re: thoughts on a possible "pre-upload" hook

[Randal L. Schwartz]

>>>>> "Sitaram" == Sitaram Chamarty <sitaramc@gmail.com> writes:

Sitaram> Hello,
Sitaram> As git is used more and more in corporate-type environments, at some
Sitaram> point it becomes convenient to have *branches* (or more accurately,
Sitaram> refs) that are not readable.  The simplest way to do this (from git's
Sitaram> point of view) is to allow a "pre-upload" hook, rather like the
Sitaram> "pre-receive" hook or "update" hook.

It would seem that you would need to do this even before the commit.  So
you're looking for the pre-commit hook.  Otherwise, the commit is invalid,
because it doesn't accurately represent everything it references.  And the
commit is the unit of transfer between repos.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: thoughts on a possible "pre-upload" hook

[Matthieu Moy]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Sitaram" == Sitaram Chamarty <sitaramc@gmail.com> writes:
>
> Sitaram> Hello,
> Sitaram> As git is used more and more in corporate-type environments, at some
> Sitaram> point it becomes convenient to have *branches* (or more accurately,
> Sitaram> refs) that are not readable.  The simplest way to do this (from git's
> Sitaram> point of view) is to allow a "pre-upload" hook, rather like the
> Sitaram> "pre-receive" hook or "update" hook.
>
> It would seem that you would need to do this even before the commit.  So
> you're looking for the pre-commit hook.  Otherwise, the commit is invalid,
> because it doesn't accurately represent everything it references.  And the
> commit is the unit of transfer between repos.

I don't get the point. The OP's question is not about commiting, but
about preventing a branch from being fetched. So, right before sending
the commits in a branch, the server would execute a hook, and fail if
it's not allowed.

But that alone would make it rather painfull for the user : "git
clone" would fail if any branch in the repository is not readable, for
example.

Also, don't forget that branches are just references, which means that
if you prevent reference A from being uploaded, then another reference
B may point to the same commits as A, and then you can bypass the
safety hook on A by using B.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: thoughts on a possible "pre-upload" hook

[Shawn O. Pearce]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> >>>>>> "Sitaram" == Sitaram Chamarty <sitaramc@gmail.com> writes:
> > Sitaram> As git is used more and more in corporate-type environments, at some
> > Sitaram> point it becomes convenient to have *branches* (or more accurately,
> > Sitaram> refs) that are not readable.
> 
> But that alone would make it rather painfull for the user : "git
> clone" would fail if any branch in the repository is not readable, for
> example.

No, what Sitaram is asking for is to have upload-pack not advertise
the hidden branches.  By not advertising them, the client cannot
send a "want" request for them, and they won't appear in the list
that clone believes exists when it creates the new local repository.
Thus, clone would succeed.
 
> Also, don't forget that branches are just references, which means that
> if you prevent reference A from being uploaded, then another reference
> B may point to the same commits as A, and then you can bypass the
> safety hook on A by using B.

Yes.  But this is no different than having two different git
repositories, A.git and B.git.  Pushing commits from A.git into B.git
allows someone to bypass A.git's filesystem read access control by
instead reading those commits from B.git.

IOW, those who have access to the data must protect it.  You can't
do it entirely in software, especially when you don't control the
user's computer.

-- 
Shawn.

Re: thoughts on a possible "pre-upload" hook

[Sitaram Chamarty]

sorry I couldn't reply till now...

On Tue, Sep 22, 2009 at 9:47 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>> >>>>>> "Sitaram" == Sitaram Chamarty <sitaramc@gmail.com> writes:
>> > Sitaram> As git is used more and more in corporate-type environments, at some
>> > Sitaram> point it becomes convenient to have *branches* (or more accurately,
>> > Sitaram> refs) that are not readable.
>>
>> But that alone would make it rather painfull for the user : "git
>> clone" would fail if any branch in the repository is not readable, for
>> example.
>
> No, what Sitaram is asking for is to have upload-pack not advertise
> the hidden branches.  By not advertising them, the client cannot
> send a "want" request for them, and they won't appear in the list
> that clone believes exists when it creates the new local repository.
> Thus, clone would succeed.

yes that would be precisely what I meant.  The hook would (somehow) be
able to influence which, among the available ones, get advertised.

>> Also, don't forget that branches are just references, which means that
>> if you prevent reference A from being uploaded, then another reference
>> B may point to the same commits as A, and then you can bypass the
>> safety hook on A by using B.
>
> Yes.  But this is no different than having two different git
> repositories, A.git and B.git.  Pushing commits from A.git into B.git
> allows someone to bypass A.git's filesystem read access control by
> instead reading those commits from B.git.

yes indeed -- if someone were to foolishly merge a "secret" branch
into a "normal" branch, so that it is now reachable from a "normal"
branch, that's his problem -- that cannot be within the scope of this
check.

It's the user's job to make sure that *only* his "secret" branch can
reach the secret stuff, other branches cannot reach it, and all git
has to do is ensure that no one can "want" that branch if they're not
supposed to see it.

-- 
Sitaram

Re: thoughts on a possible "pre-upload" hook

[Matthieu Moy]

Sitaram Chamarty <sitaramc@gmail.com> writes:

> yes indeed -- if someone were to foolishly merge a "secret" branch
> into a "normal" branch, so that it is now reachable from a "normal"
> branch, that's his problem -- that cannot be within the scope of this
> check.

Merging is not the only scenario. Adding a tag could make secret
things become visible too. I'm not saying the approach isn't viable,
but if it gets implemented, it should be done with care to make sure
there's no easy mis-use that would lead to reveal a secret (typically,
I'd do that with a whitelist and not a black-list, so that new
references are secret by default).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: thoughts on a possible "pre-upload" hook

[Sitaram Chamarty]

On Fri, Sep 25, 2009 at 5:59 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> yes indeed -- if someone were to foolishly merge a "secret" branch
>> into a "normal" branch, so that it is now reachable from a "normal"
>> branch, that's his problem -- that cannot be within the scope of this
>> check.
>
> Merging is not the only scenario. Adding a tag could make secret
> things become visible too. I'm not saying the approach isn't viable,
> but if it gets implemented, it should be done with care to make sure
> there's no easy mis-use that would lead to reveal a secret (typically,
> I'd do that with a whitelist and not a black-list, so that new
> references are secret by default).

A whitelist may be better, but I'd be quite happy with a blacklist, if
that's easier to implement, and take on myself/my team the onus of
ensuring that code remains unreachable from any of the non-blacklisted
tags.

In other words, I don't expect this to be idiot-proof and I'll take
what I can get and work with it :-)

-- 
Sitaram

Re: thoughts on a possible "pre-upload" hook

[Adam Brewster]

> As git is used more and more in corporate-type environments, at some
> point it becomes convenient to have *branches* (or more accurately,
> refs) that are not readable.  The simplest way to do this (from git's
> point of view) is to allow a "pre-upload" hook, rather like the
> "pre-receive" hook or "update" hook.
>

What's the benefit of this over using multiple repositories?

For a simple case where you have public branches and private branches,
you use public.git and private.git.  A post-update hook in private.git
can automatically push the appropriate branches to public.git (in
which case they don't worry about public.git at all) or they can do it
themselves.

For more complex access control, give each sub-unit that needs to
share work a repository that's only readable by the members of that
unit.  Each developer works in his own repo.  When something is ready
for a wider audience, he pushes it to a team repo.  When a team leader
has something that's ready to move up, he pushes to a group repo, etc.

--
Adam

Re: thoughts on a possible "pre-upload" hook

[Sitaram Chamarty]

On Mon, Sep 28, 2009 at 7:31 AM, Adam Brewster <adambrewster@gmail.com> wrote:
>> As git is used more and more in corporate-type environments, at some
>> point it becomes convenient to have *branches* (or more accurately,
>> refs) that are not readable.  The simplest way to do this (from git's
>> point of view) is to allow a "pre-upload" hook, rather like the
>> "pre-receive" hook or "update" hook.
>>
>
> What's the benefit of this over using multiple repositories?

Over a long pm chat over irc with Ilari, I have come to the same
conclusion.  I was hoping there would be some administrative
convenience or workflow convenience to doing this, but whether there
is or not is debatable, and even if there is, there are enough failure
modes to make this have a lot of caveats.

-- 
Sitaram