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. -- 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