On Sun, Nov 27, 2011 at 2:26 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> writes: > >> Just because it is passed through the environment does not mean you need >> to have it set all the time. There is nothing wrong with: >> >> GIT_ALLOW_UNTRUSTED_HOOKS=true git fetch ~bob/repo.git >> >> We can even spell it: >> >> git --allow-untrusted-hooks fetch ~bob/repo.git >> >> but it should probably still end up as an environment variable to make >> it through to the remote side (you could also tack it on to the >> upload-pack command line; that wouldn't make it across git:// or http:// >> connections, but those are irrelevant here anyway). > > I actually like the idea of allowing pre-upload-pack hook on git:// and > possibly http:// only. git-daemon can tell the upload-pack that it is OK > to run the hook, and the hook can do the things that only the daemon can > do, never touching what the original requestor would but the repository > owner would not have an access to. Normal file:// and ssh:// transfer > should not be needed for GitHub's stats or Sitaram's proxy usage, and we > should be able to unconditionally disable the hook when transfer is going > over these protocols, no? > > One scenario I do not want to see is this. Suppose there is a company that > runs more than one project, and one of the projects is so secret that only > engineers working on the project have access to its repository, while all > people, including the project-A engineers, in the company have access to > other repositories. Further suppose that people involved in some or many > of the general repositories want to do something before a fetch from them > happens. They will use the pre-upload-hook to implement it if we make it > available, and their new-hire training course will tell their engineers to > set the GIT_ALLOW_UNTRUSTED_HOOKS. Perhaps the /etc/skel/profile the > company gives the new-hires already defines it. > > And somebody who controls one of the general repositories installs a > pre-upload-hook that borrows credential of a project-A engineer who > happens to fetch from it to access repositories of the project-A. > > Imagine how the blame game that will ensue goes after materials from > project-A is exposed. Of course, the owner of the rogue hook will get the > first blame, but I do not think Git will come unscathed out of it. At > least we will be blamed for adding an inherently unsafe mechanism. > I'm sorry I started this discussion. I worked around it, though it's a bit kludgy, so maybe time to drop the debate. -- Sitaram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html