{"thread":{"id":"21023","subject":"thoughts on a possible \"pre-upload\" hook","startedAt":"2009-09-22T10:20:09Z","lastAt":"2009-09-28T03:02:17Z","messageCount":9,"participants":["Sitaram Chamarty","Randal L. Schwartz","Matthieu Moy","Shawn O. Pearce","Adam Brewster"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"123621","messageId":"2e24e5b90909220320rbd5fd1l40c7898656445232@mail.gmail.com","threadId":"21023","inReplyTo":null,"subject":"thoughts on a possible \"pre-upload\" hook","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-09-22T10:20:09Z","receivedAt":"2009-09-22T10:20:09Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"Hello,\n\nAs git is used more and more in corporate-type environments, at some\npoint it becomes convenient to have *branches* (or more accurately,\nrefs) that are not readable. The simplest way to do this (from git's\npoint of view) is to allow a \"pre-upload\" hook, rather like the\n\"pre-receive\" hook or \"update\" hook.\n\nI don't know the upload pack protocol enough to know whether this is a\nstupid idea or not; please tell me if so :-) But things that were\nseemingly \"impossible\" in the early days are being talked about now\nand even being implemented so I felt brave enough to ask.\n\nI'm afraid my C programming days are long gone, but if anything can be\ndone in shell or perl, with a little git.guidance, I'll do whatever I\ncan.\n\n-- \nSitaram\n"},{"id":"123635","messageId":"867hvr2cms.fsf@blue.stonehenge.com","threadId":"21023","inReplyTo":"2e24e5b90909220320rbd5fd1l40c7898656445232@mail.gmail.com","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2009-09-22T16:00:11Z","receivedAt":"2009-09-22T16:00:11Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Sitaram\" == Sitaram Chamarty writes:\n\nSitaram> Hello,\nSitaram> As git is used more and more in corporate-type environments, at some\nSitaram> point it becomes convenient to have *branches* (or more accurately,\nSitaram> refs) that are not readable. The simplest way to do this (from git's\nSitaram> point of view) is to allow a \"pre-upload\" hook, rather like the\nSitaram> \"pre-receive\" hook or \"update\" hook.\n\nIt would seem that you would need to do this even before the commit. So\nyou're looking for the pre-commit hook. Otherwise, the commit is invalid,\nbecause it doesn't accurately represent everything it references. And the\ncommit is the unit of transfer between repos.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"123637","messageId":"vpqd45jvub6.fsf@bauges.imag.fr","threadId":"21023","inReplyTo":"867hvr2cms.fsf@blue.stonehenge.com","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-09-22T16:05:33Z","receivedAt":"2009-09-22T16:05:33Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Sitaram\" == Sitaram Chamarty writes:\n>\n> Sitaram> Hello,\n> Sitaram> As git is used more and more in corporate-type environments, at some\n> Sitaram> point it becomes convenient to have *branches* (or more accurately,\n> Sitaram> refs) that are not readable. The simplest way to do this (from git's\n> Sitaram> point of view) is to allow a \"pre-upload\" hook, rather like the\n> Sitaram> \"pre-receive\" hook or \"update\" hook.\n>\n> It would seem that you would need to do this even before the commit. So\n> you're looking for the pre-commit hook. Otherwise, the commit is invalid,\n> because it doesn't accurately represent everything it references. And the\n> commit is the unit of transfer between repos.\n\nI don't get the point. The OP's question is not about commiting, but\nabout preventing a branch from being fetched. So, right before sending\nthe commits in a branch, the server would execute a hook, and fail if\nit's not allowed.\n\nBut that alone would make it rather painfull for the user : \"git\nclone\" would fail if any branch in the repository is not readable, for\nexample.\n\nAlso, don't forget that branches are just references, which means that\nif you prevent reference A from being uploaded, then another reference\nB may point to the same commits as A, and then you can bypass the\nsafety hook on A by using B.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"123639","messageId":"20090922161725.GS14660@spearce.org","threadId":"21023","inReplyTo":"vpqd45jvub6.fsf@bauges.imag.fr","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-09-22T16:17:25Z","receivedAt":"2009-09-22T16:17:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthieu Moy wrote:\n> >>>>>> \"Sitaram\" == Sitaram Chamarty writes:\n> > Sitaram> As git is used more and more in corporate-type environments, at some\n> > Sitaram> point it becomes convenient to have *branches* (or more accurately,\n> > Sitaram> refs) that are not readable.\n> \n> But that alone would make it rather painfull for the user : \"git\n> clone\" would fail if any branch in the repository is not readable, for\n> example.\n\nNo, what Sitaram is asking for is to have upload-pack not advertise\nthe hidden branches. By not advertising them, the client cannot\nsend a \"want\" request for them, and they won't appear in the list\nthat clone believes exists when it creates the new local repository.\nThus, clone would succeed.\n \n> Also, don't forget that branches are just references, which means that\n> if you prevent reference A from being uploaded, then another reference\n> B may point to the same commits as A, and then you can bypass the\n> safety hook on A by using B.\n\nYes. But this is no different than having two different git\nrepositories, A.git and B.git. Pushing commits from A.git into B.git\nallows someone to bypass A.git's filesystem read access control by\ninstead reading those commits from B.git.\n\nIOW, those who have access to the data must protect it. You can't\ndo it entirely in software, especially when you don't control the\nuser's computer.\n\n-- \nShawn.\n"},{"id":"123769","messageId":"2e24e5b90909250454s7ed35b9ch10b954b0b1a40cfe@mail.gmail.com","threadId":"21023","inReplyTo":"20090922161725.GS14660@spearce.org","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-09-25T11:54:36Z","receivedAt":"2009-09-25T11:54:36Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"sorry I couldn't reply till now...\n\nOn Tue, Sep 22, 2009 at 9:47 PM, Shawn O. Pearce wrote:\n> Matthieu Moy wrote:\n>> >>>>>> \"Sitaram\" == Sitaram Chamarty writes:\n>> > Sitaram> As git is used more and more in corporate-type environments, at some\n>> > Sitaram> point it becomes convenient to have *branches* (or more accurately,\n>> > Sitaram> refs) that are not readable.\n>>\n>> But that alone would make it rather painfull for the user : \"git\n>> clone\" would fail if any branch in the repository is not readable, for\n>> example.\n>\n> No, what Sitaram is asking for is to have upload-pack not advertise\n> the hidden branches.  By not advertising them, the client cannot\n> send a \"want\" request for them, and they won't appear in the list\n> that clone believes exists when it creates the new local repository.\n> Thus, clone would succeed.\n\nyes that would be precisely what I meant. The hook would (somehow) be\nable to influence which, among the available ones, get advertised.\n\n>> Also, don't forget that branches are just references, which means that\n>> if you prevent reference A from being uploaded, then another reference\n>> B may point to the same commits as A, and then you can bypass the\n>> safety hook on A by using B.\n>\n> Yes.  But this is no different than having two different git\n> repositories, A.git and B.git.  Pushing commits from A.git into B.git\n> allows someone to bypass A.git's filesystem read access control by\n> instead reading those commits from B.git.\n\nyes indeed -- if someone were to foolishly merge a \"secret\" branch\ninto a \"normal\" branch, so that it is now reachable from a \"normal\"\nbranch, that's his problem -- that cannot be within the scope of this\ncheck.\n\nIt's the user's job to make sure that *only* his \"secret\" branch can\nreach the secret stuff, other branches cannot reach it, and all git\nhas to do is ensure that no one can \"want\" that branch if they're not\nsupposed to see it.\n\n-- \nSitaram\n"},{"id":"123771","messageId":"vpqab0j1a2s.fsf@bauges.imag.fr","threadId":"21023","inReplyTo":"2e24e5b90909250454s7ed35b9ch10b954b0b1a40cfe@mail.gmail.com","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-09-25T12:29:47Z","receivedAt":"2009-09-25T12:29:47Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sitaram Chamarty writes:\n\n> yes indeed -- if someone were to foolishly merge a \"secret\" branch\n> into a \"normal\" branch, so that it is now reachable from a \"normal\"\n> branch, that's his problem -- that cannot be within the scope of this\n> check.\n\nMerging is not the only scenario. Adding a tag could make secret\nthings become visible too. I'm not saying the approach isn't viable,\nbut if it gets implemented, it should be done with care to make sure\nthere's no easy mis-use that would lead to reveal a secret (typically,\nI'd do that with a whitelist and not a black-list, so that new\nreferences are secret by default).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"123774","messageId":"2e24e5b90909250643s5fb469f8x6974fed96aba4db4@mail.gmail.com","threadId":"21023","inReplyTo":"vpqab0j1a2s.fsf@bauges.imag.fr","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-09-25T13:43:16Z","receivedAt":"2009-09-25T13:43:16Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Fri, Sep 25, 2009 at 5:59 PM, Matthieu Moy\n wrote:\n> Sitaram Chamarty writes:\n>\n>> yes indeed -- if someone were to foolishly merge a \"secret\" branch\n>> into a \"normal\" branch, so that it is now reachable from a \"normal\"\n>> branch, that's his problem -- that cannot be within the scope of this\n>> check.\n>\n> Merging is not the only scenario. Adding a tag could make secret\n> things become visible too. I'm not saying the approach isn't viable,\n> but if it gets implemented, it should be done with care to make sure\n> there's no easy mis-use that would lead to reveal a secret (typically,\n> I'd do that with a whitelist and not a black-list, so that new\n> references are secret by default).\n\nA whitelist may be better, but I'd be quite happy with a blacklist, if\nthat's easier to implement, and take on myself/my team the onus of\nensuring that code remains unreachable from any of the non-blacklisted\ntags.\n\nIn other words, I don't expect this to be idiot-proof and I'll take\nwhat I can get and work with it :-)\n\n-- \nSitaram\n"},{"id":"123911","messageId":"c376da900909271901q1667ecacw730ba5180a558f3b@mail.gmail.com","threadId":"21023","inReplyTo":"2e24e5b90909220320rbd5fd1l40c7898656445232@mail.gmail.com","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Adam Brewster","fromEmail":"adambrewster@gmail.com","sentAt":"2009-09-28T02:01:09Z","receivedAt":"2009-09-28T02:01:09Z","isPatch":false,"sender":{"key":"adambrewster@gmail.com","avatar":"https://avatars.githubusercontent.com/u/223816?v=4"},"body":"> As git is used more and more in corporate-type environments, at some\n> point it becomes convenient to have *branches* (or more accurately,\n> refs) that are not readable.  The simplest way to do this (from git's\n> point of view) is to allow a \"pre-upload\" hook, rather like the\n> \"pre-receive\" hook or \"update\" hook.\n>\n\nWhat's the benefit of this over using multiple repositories?\n\nFor a simple case where you have public branches and private branches,\nyou use public.git and private.git. A post-update hook in private.git\ncan automatically push the appropriate branches to public.git (in\nwhich case they don't worry about public.git at all) or they can do it\nthemselves.\n\nFor more complex access control, give each sub-unit that needs to\nshare work a repository that's only readable by the members of that\nunit. Each developer works in his own repo. When something is ready\nfor a wider audience, he pushes it to a team repo. When a team leader\nhas something that's ready to move up, he pushes to a group repo, etc.\n\n--\nAdam\n"},{"id":"123914","messageId":"2e24e5b90909272002r53b0a82dw9cb52bdc7bbd477@mail.gmail.com","threadId":"21023","inReplyTo":"c376da900909271901q1667ecacw730ba5180a558f3b@mail.gmail.com","subject":"Re: thoughts on a possible \"pre-upload\" hook","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-09-28T03:02:17Z","receivedAt":"2009-09-28T03:02:17Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Mon, Sep 28, 2009 at 7:31 AM, Adam Brewster wrote:\n>> As git is used more and more in corporate-type environments, at some\n>> point it becomes convenient to have *branches* (or more accurately,\n>> refs) that are not readable.  The simplest way to do this (from git's\n>> point of view) is to allow a \"pre-upload\" hook, rather like the\n>> \"pre-receive\" hook or \"update\" hook.\n>>\n>\n> What's the benefit of this over using multiple repositories?\n\nOver a long pm chat over irc with Ilari, I have come to the same\nconclusion. I was hoping there would be some administrative\nconvenience or workflow convenience to doing this, but whether there\nis or not is debatable, and even if there is, there are enough failure\nmodes to make this have a lot of caveats.\n\n-- \nSitaram\n"}]}