(...and/or a post-upload hook)

Has this ever come up?

--
Sitaram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

 Yes, previously it was seen as problematic (potentially too slow), but we are now open to having one.  Patches welcome.  :)

Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Doh sorry, I thought this was a Gerrit question!  (Wrong mailing list)

Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sorry for the google-fu fail and for replying to my own post.
http://git.661346.n2.nabble.com/Removal-of-post-upload-hook-td4394312...
is the longest thread I (later) found.

The quick summary, in the words of Jeff (second post in that link) is:
"Because [upload]-pack runs as the user who is [fetching], not as the
repository owner. So by convincing you to [fetch from] my repository
in a multi-user environment, I convince you to run some arbitrary code
of mine."

My contention (today) is:

  - you're already taking that risk for push
  - so this would add a new risk only for people who fetch but don't push
  - which, I submit, is a very small (if not almost empty) set of people

I may be wrong but I imagine shared environments are those where
almost everyone will push at least once in a while.  It's a closed
group of people, probably all developers, etc etc etc...

Thanks for listening.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 11/25/2011 05:13 AM, Sitaram Chamarty wrote:

People who fetch but don't push is, by far, the vast majority of git users.
Think of everyone fetching from any public software repository without
having write access to it. If you think of git.git and linux.git alone
I think it's safe to assume the number of "fetch-no-push" outnumber the
"push-and-whatnot" group by some quarter million to one.

Not really. We fetch from each other quite a lot at work, and from
each others semi-public repositories on a shared server where we've
all got accounts (ie, write access), but we very, very rarely push
into each others repositories. The sharepoint is the "official" repo
on the repo-server, which the buildbots gets its code from and where
everything to be released, maintained or handled in some way in the
future resides.

Anyways. Shooting down the arguments *against* pre-upload hooks are
quite silly if it's not combined with some fresh arguments *for* such
a hook.

So... What usecase do you envision where you'd need one?

--
Andreas Ericsson                   andreas.erics...@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

One thing to note is that this is _only_ an issue on systems where the
user running upload-pack (or receive-pack, for push) is not the same as
the user who owns the hooks directory. So basically two situations:

  1. Alice and Bob are developers on a multi-user system with ssh
     access. Alice will run "git fetch ~bob/project.git" or "git fetch
     alice@server:~bob/project.git". She executes Bob's hooks as
     herself on the server.

  2. Somebody runs a git:// server, locked down under a "git" user (or a
     smart-http server, under a "www" account).  If users of the service
     can write their own hooks, they will run as the "git" user.

But there are many situations that don't fall under this umbrella. In
(1), maybe Alice and Bob decide that they trust each other enough, and
the hook is more important than the security issue. In (2), users of the
service might not be able to write their own hooks (this is the case for
GitHub, and I assume also for Gerrit).

There should be a way for people who aren't in one of those dangerous
situations to be able to use a hook. The important thing is to set the
defaults in such a way that the people who _are_ in that situation
aren't left in a vulnerable situation.

The easiest way would be something like a "trust remote hooks"
environment variable, off by default. Admins in situation (2) could set
it for their git-daemon (or webserver, or whatever, or
gitolite-over-ssh), once they decided it was safe.

It could also help with (1), but I think you would need to take special
steps to propagate the variable in the "git fetch server:project.git"
case.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

But in those environments the person pulling does not even have an ID
so how is he at risk with the hook running?

Yes, and this is the only situation where it does have the issue.  I'm
just not sure how common this is.

It's fine if you tell me I'm wrong and that this *is* still very
common.  I'll back off.

But everyone seems to be bringing in github and public repos as part
of the argument, and I don't see how they're relevant to the original
security issue of the guy who pulls having his account compromised.

I'm writing a caching proxy that helps with bandwidth issues when too
many people in a bad-WAN site want to clone some huge repo from its
canonical site.  The only one I found by googling fiddles with the git
protocol itself, and I hate doing things like that.

Ignoring all the details, the pre-upload hook would have checked some
conditions and fired off a fetch from the remote site if those checks
passed.

It's easy enough to do it from cron but it would have been more
elegant this way.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html