merlyn@stonehenge.com (Randal L. Schwartz) writes:
quoted
quoted
quoted
quoted
quoted
"Sitaram" == Sitaram Chamarty [off-list ref] 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/
Matthieu Moy [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
quoted
"Sitaram" == Sitaram Chamarty [off-list ref] 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.
sorry I couldn't reply till now...
On Tue, Sep 22, 2009 at 9:47 PM, Shawn O. Pearce [off-list ref] wrote:
Matthieu Moy [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
quoted
quoted
"Sitaram" == Sitaram Chamarty [off-list ref] 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.
quoted
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