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

> Jeff King <peff@peff.net> 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.
>