git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: what are the chances of a 'pre-upload' hook?

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 27, 2011, 07:51 UTC
Message-ID
<7vmxbivw8u.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20111126233133.GA31129@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> It depends on what you want your hook to do. I thought Sitaram's
> use-case was putting something like "git fetch upstream" into a hook
> that runs before upload-pack, to create a transparent proxy. That has
> nothing to do with the accessing user.
>
> At GitHub, we run a pre-upload-pack hook to keep statistics. That has
> nothing to do with the accessing user. We have to patch git to provide
> the hook.

I personally have a huge problem with shipping an inherently unsafe mechanism that is disabled by default even if it is marked with big red letters saying that it is unsafe and should not be enabled casually. It makes it up to the system administrator to decide what is casual and what is not, but when end users are get harmed by a clueless administrator's decision, the repercussion will come back to the Git software, not to the clueless administrator who enabled an unsafe mechanism in an environment where it was not designed to support.

It may merely be a matter of perception. After all, the pre-upload-pack hook I did in a8563ec (upload-pack: add a trigger for post-upload-pack hook, 2009-08-26) in response to GitHub's stat request was so trivial that even clueless admins could trojan it back into the current upload-pack source to use in their own site, without letting their users know that their fetch request may be opening their account to a random hook script. So in that sense, it might not be worth my effort to fight for Git users' safety to find a better solution and instead go with the big red letter approach which is easy. I know perfect is an enemy of good, but when I do not think an easy Quick-and-Dirty solution is even less than good, I need to point out that not having less than bad is better than having it.

If the mechanism to notify the external machinery (i.e. counting accesses, learning the true destination of a new fetch request and have the fetcher wait while the real fetch goes to the origin site) were not via a hook that runs as the fetcher but were via something else that runs as the owner of that external service (i.e. counting accesses, maintaining the proxy object pool), I wouldn't have trouble with the proposal.

For example, upload-pack could write the details of the original request to a named pipe to ask the "service" process listening on the other end, and wait for its response.

Previous: Jeff KingNext: Jeff King
Message 12 of 23 in “what are the chances of a 'pre-upload' hook?”
  1. Sitaram ChamartyNov 25, 2011
  2. Martin FickNov 25, 2011
  3. Martin FickNov 25, 2011
  4. Sitaram ChamartyNov 25, 2011
  5. Andreas EricssonNov 25, 2011
  6. Sitaram ChamartyNov 25, 2011
  7. Jeff KingNov 25, 2011
  8. Junio C HamanoNov 26, 2011
  9. Jeff KingNov 26, 2011
  10. Junio C HamanoNov 26, 2011
  11. Jeff KingNov 26, 2011
  12. Junio C HamanoNov 27, 2011
  13. Jeff KingNov 26, 2011
  14. Jeff KingNov 27, 2011
  15. Junio C HamanoNov 27, 2011
  16. Sitaram ChamartyNov 27, 2011
  17. Junio C HamanoNov 28, 2011
  18. Jeff KingNov 28, 2011
  19. Sitaram ChamartyNov 28, 2011
  20. Sitaram ChamartyNov 28, 2011
  21. Jeff KingNov 28, 2011
  22. Jeff KingNov 28, 2011
  23. Jeff KingNov 28, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.