{"thread":{"id":"27365","subject":"ACLs for GIT","startedAt":"2011-05-15T19:24:38Z","lastAt":"2011-05-17T15:41:44Z","messageCount":15,"participants":["Martin L Resnick","Magnus Bäck","R. Tyler Croy","Marc Weber","Richard Peterson","Phil Hord","Jakub Narebski","Sitaram Chamarty","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167914","messageId":"4DD02876.1040404@bbn.com","threadId":"27365","inReplyTo":null,"subject":"ACLs for GIT","fromName":"Martin L Resnick","fromEmail":"mresnick@bbn.com","sentAt":"2011-05-15T19:24:38Z","receivedAt":"2011-05-15T19:24:38Z","isPatch":false,"sender":{"key":"mresnick@bbn.com","avatar":null},"body":"Is anyone working on adding access control to GIT ?\n\nI'm looking for the Subversion equivalent of mod_authz_svn.\nI need to restrict read access of ITAR documents that are\nscattered throughout the source tree.\nThis restriction would need to deny fetch of the ITAR\ndocuments yet allow fetch of any other files.\n\nLooking through the source code it would seem that\nputting a hook call in the fetch-pack code would do it.\n\nThanks\n"},{"id":"167916","messageId":"20110515201513.GA27758@jpl.local","threadId":"27365","inReplyTo":"4DD02876.1040404@bbn.com","subject":"Re: ACLs for GIT","fromName":"Magnus Bäck","fromEmail":"magnus.back@sonyericsson.com","sentAt":"2011-05-15T20:15:13Z","receivedAt":"2011-05-15T20:15:13Z","isPatch":false,"sender":{"key":"magnus.back@sonyericsson.com","avatar":null},"body":"On Sunday, May 15, 2011 at 21:24 CEST,\n Martin L Resnick wrote:\n\n> Is anyone working on adding access control to GIT ?\n>\n> I'm looking for the Subversion equivalent of mod_authz_svn.\n> I need to restrict read access of ITAR documents that are\n> scattered throughout the source tree.\n> This restriction would need to deny fetch of the ITAR\n> documents yet allow fetch of any other files.\n>\n> Looking through the source code it would seem that\n> putting a hook call in the fetch-pack code would do it.\n\nI doubt it would make sense to put per-file permissions in Git\nas it doesn't version files but the complete state of a workspace.\nEven if you manage to hack the pack code to not include certain\nblobs when certain users ask for them, what would those users\ndo when they want to create new commits based on commits where\nblobs are missing? Or would you send the protected blobs but\nreplace their contents? Then Git would complain about that.\n\nHowever, both Gerrit Code Review and Gitolite offer per-branch\npermissions, so if it would be possible to put these files on\nbranches of their own these tools would help.\n\n-- \nMagnus Bäck Opinions are my own and do not necessarily\nSW Configuration Manager represent the ones of my employer, etc.\nSony Ericsson\n"},{"id":"167917","messageId":"20110515201608.GX6349@kiwi.flexilis.local","threadId":"27365","inReplyTo":"4DD02876.1040404@bbn.com","subject":"Re: ACLs for GIT","fromName":"R. Tyler Croy","fromEmail":"tyler@monkeypox.org","sentAt":"2011-05-15T20:16:08Z","receivedAt":"2011-05-15T20:16:08Z","isPatch":false,"sender":{"key":"tyler@monkeypox.org","avatar":"https://gravatar.com/avatar/f523ae06c1aa78f1b4c13bd5dd6fe4c716ec72c0857fcb187f1c7f0e2d2b0ba1?d=mp&s=160"},"body":"\nOn Sun, 15 May 2011, Martin L Resnick wrote:\n\n> Is anyone working on adding access control to GIT ?\n> \n> I'm looking for the Subversion equivalent of mod_authz_svn.\n> I need to restrict read access of ITAR documents that are\n> scattered throughout the source tree.\n> This restriction would need to deny fetch of the ITAR\n> documents yet allow fetch of any other files.\n> \n> Looking through the source code it would seem that\n> putting a hook call in the fetch-pack code would do it.\n\nIt sounds like 'gitolite' might be what you're looking for:\n\n\n- R. Tyler Croy\n--------------------------------------\n Code: http://github.com/rtyler\n Chatter: http://identi.ca/agentdero\n http://twitter.com/agentdero\n"},{"id":"167920","messageId":"1305490853-sup-1446@nixos","threadId":"27365","inReplyTo":"4DD02876.1040404@bbn.com","subject":"Re: ACLs for GIT","fromName":"Marc Weber","fromEmail":"marco-oweber@gmx.de","sentAt":"2011-05-15T20:28:06Z","receivedAt":"2011-05-15T20:28:06Z","isPatch":false,"sender":{"key":"marco-oweber@gmx.de","avatar":null},"body":"Excerpts from Martin L Resnick's message of Sun May 15 21:24:38 +0200 2011:\n> Is anyone working on adding access control to GIT ?\n\nI don't know git internals very well. But my very basic understanding is\nthat each commit hash is based on *all* file contents and path names and its history.\n\nIf you drop some paths (eg by denying access) there is no way to verify\nor recalculate the hashes ?\n\nSo even if you can deny access to some path I'd expect the result to be\nunusable because all kinds of tools such as gitk will start telling you\nabout missing paths.\n\n\nAlternative ideas:\n\n- github supports SVN access to git repos. Maybe you can ask them to\n provide what you're looking for?\n\n- clone the repo and strip off the files. Then allow access to those\n cloned striped repos only.\n\nI don't think there is a simple solution to your request. But others may\nknow better than I do.\n\nMarc Weber\n"},{"id":"167993","messageId":"4DD1250D.50005@bbn.com","threadId":"27365","inReplyTo":"20110515201513.GA27758@jpl.local","subject":"Re: ACLs for GIT","fromName":"Martin L Resnick","fromEmail":"mresnick@bbn.com","sentAt":"2011-05-16T13:22:21Z","receivedAt":"2011-05-16T13:22:21Z","isPatch":false,"sender":{"key":"mresnick@bbn.com","avatar":null},"body":"Thanks Mangus.\n\nYou pointed out some hurdles I'll have to think about\n(blocked files not matching the SHA and so can't be committed).\n\nAs to why I want to do this consider NSA non-export rules.\nOur application would be built with NSA encryption\nbut we have foreign nationals working on the code\nand so they are not permitted to see that part.\nThe makefiles look to see if the NSA encryption code file\nis there and link it in. If not a stub is used.\n\n\nOn 05/15/2011 04:15 PM, Magnus Bäck wrote:\n> On Sunday, May 15, 2011 at 21:24 CEST,\n> Martin L Resnick wrote:\n>\n>> Is anyone working on adding access control to GIT ?\n>>\n>> I'm looking for the Subversion equivalent of mod_authz_svn.\n>> I need to restrict read access of ITAR documents that are\n>> scattered throughout the source tree.\n>> This restriction would need to deny fetch of the ITAR\n>> documents yet allow fetch of any other files.\n>>\n>> Looking through the source code it would seem that\n>> putting a hook call in the fetch-pack code would do it.\n>\n> I doubt it would make sense to put per-file permissions in Git\n> as it doesn't version files but the complete state of a workspace.\n> Even if you manage to hack the pack code to not include certain\n> blobs when certain users ask for them, what would those users\n> do when they want to create new commits based on commits where\n> blobs are missing? Or would you send the protected blobs but\n> replace their contents? Then Git would complain about that.\n>\n> However, both Gerrit Code Review and Gitolite offer per-branch\n> permissions, so if it would be possible to put these files on\n> branches of their own these tools would help.\n>\n"},{"id":"167994","messageId":"4DD12517.1000308@bbn.com","threadId":"27365","inReplyTo":"20110515201608.GX6349@kiwi.flexilis.local","subject":"Re: ACLs for GIT","fromName":"Martin L Resnick","fromEmail":"mresnick@bbn.com","sentAt":"2011-05-16T13:22:31Z","receivedAt":"2011-05-16T13:22:31Z","isPatch":false,"sender":{"key":"mresnick@bbn.com","avatar":null},"body":"Thanks for the reply.\n\nBut gitolite would only work to deny reads on a repository or ref basis\nnot a pathname level.\n\n\nOn 05/15/2011 04:16 PM, R. Tyler Croy wrote:\n>\n> On Sun, 15 May 2011, Martin L Resnick wrote:\n>\n>> Is anyone working on adding access control to GIT ?\n>>\n>> I'm looking for the Subversion equivalent of mod_authz_svn.\n>> I need to restrict read access of ITAR documents that are\n>> scattered throughout the source tree.\n>> This restriction would need to deny fetch of the ITAR\n>> documents yet allow fetch of any other files.\n>>\n>> Looking through the source code it would seem that\n>> putting a hook call in the fetch-pack code would do it.\n>\n> It sounds like 'gitolite' might be what you're looking for:\n> \n>\n> - R. Tyler Croy\n> --------------------------------------\n> Code: http://github.com/rtyler\n> Chatter: http://identi.ca/agentdero\n> http://twitter.com/agentdero\n"},{"id":"167998","messageId":"BANLkTimMP3aJrQ-ivzR+yOhb12t-qQTz2Q@mail.gmail.com","threadId":"27365","inReplyTo":"4DD1250D.50005@bbn.com","subject":"Re: ACLs for GIT","fromName":"Richard Peterson","fromEmail":"richard@rcpeterson.com","sentAt":"2011-05-16T15:26:38Z","receivedAt":"2011-05-16T15:26:38Z","isPatch":false,"sender":{"key":"richard@rcpeterson.com","avatar":"https://gravatar.com/avatar/cc6d791c99e8302288a850cd4477a28bb7782b1133b03a45f7b7e0f93624390f?d=mp&s=160"},"body":"On Mon, May 16, 2011 at 9:22 AM, Martin L Resnick wrote:\n> Thanks Mangus.\n>\n> You pointed out some hurdles I'll have to think about\n> (blocked files not matching the SHA and so can't be committed).\n>\n> As to why I want to do this consider NSA non-export rules.\n> Our application would be built with NSA encryption\n> but we have foreign nationals working on the code\n> and so they are not permitted to see that part.\n> The makefiles look to see if the NSA encryption code file\n> is there and link it in. If not a stub is used.\n\nI bet you could use a submodule.\n\n-Richard\n"},{"id":"167999","messageId":"4DD143CA.3000700@cisco.com","threadId":"27365","inReplyTo":"4DD1250D.50005@bbn.com","subject":"Re: ACLs for GIT","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-05-16T15:33:30Z","receivedAt":"2011-05-16T15:33:30Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 05/16/2011 09:22 AM, Martin L Resnick wrote:\n> Thanks Mangus.\n>\n> You pointed out some hurdles I'll have to think about\n> (blocked files not matching the SHA and so can't be committed).\n>\n> As to why I want to do this consider NSA non-export rules.\n> Our application would be built with NSA encryption\n> but we have foreign nationals working on the code\n> and so they are not permitted to see that part.\n> The makefiles look to see if the NSA encryption code file\n> is there and link it in. If not a stub is used.\n\nWe use submodules for this same need here. If the submodule is loaded,\nthe code is used from that. If not, pre-built binaries are used\ninstead. These could be stubs.\n\nWhen we share code with outside partners, we give them access only to\nthe modules they need.\n\nWe further guard the code in the submodule by PGP-encrypting the source\nfiles and storing them in the repository (as binaries). This practice\nlets us be more free with the repository and not worry so much that it\nmay be cloned well out of our control. Storing code as shrouded\nbinaries negates much of git's power, but only for this one submodule. \nOur other submodules are still quite git-friendly.\n\nPhil\n"},{"id":"168000","messageId":"4DD14468.1000401@bbn.com","threadId":"27365","inReplyTo":"4DD143CA.3000700@cisco.com","subject":"Re: ACLs for GIT","fromName":"Martin L Resnick","fromEmail":"mresnick@bbn.com","sentAt":"2011-05-16T15:36:08Z","receivedAt":"2011-05-16T15:36:08Z","isPatch":false,"sender":{"key":"mresnick@bbn.com","avatar":null},"body":"Wonderful. Thanks a lot.\n\nThat's a great idea to use submodules WITH encrypting the source.\n\nI like it! I'm going to propose we use it.\n\nThanks for the suggestion.\n\nOn 05/16/2011 11:33 AM, Phil Hord wrote:\n> On 05/16/2011 09:22 AM, Martin L Resnick wrote:\n>> Thanks Mangus.\n>>\n>> You pointed out some hurdles I'll have to think about\n>> (blocked files not matching the SHA and so can't be committed).\n>>\n>> As to why I want to do this consider NSA non-export rules.\n>> Our application would be built with NSA encryption\n>> but we have foreign nationals working on the code\n>> and so they are not permitted to see that part.\n>> The makefiles look to see if the NSA encryption code file\n>> is there and link it in. If not a stub is used.\n>\n> We use submodules for this same need here. If the submodule is loaded,\n> the code is used from that. If not, pre-built binaries are used\n> instead. These could be stubs.\n>\n> When we share code with outside partners, we give them access only to\n> the modules they need.\n>\n> We further guard the code in the submodule by PGP-encrypting the source\n> files and storing them in the repository (as binaries). This practice\n> lets us be more free with the repository and not worry so much that it\n> may be cloned well out of our control. Storing code as shrouded\n> binaries negates much of git's power, but only for this one submodule.\n> Our other submodules are still quite git-friendly.\n>\n> Phil\n>\n>\n"},{"id":"168004","messageId":"m3oc32zk4a.fsf@localhost.localdomain","threadId":"27365","inReplyTo":"4DD1250D.50005@bbn.com","subject":"Re: ACLs for GIT","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-16T16:28:17Z","receivedAt":"2011-05-16T16:28:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Martin L Resnick writes:\n> On 05/15/2011 04:15 PM, Magnus Bäck wrote:\n>> On Sunday, May 15, 2011 at 21:24 CEST,\n>> Martin L Resnick wrote:\n>>\n>>> Is anyone working on adding access control to GIT ?\n>>>\n>>> I'm looking for the Subversion equivalent of mod_authz_svn.\n>>> I need to restrict read access of ITAR documents that are\n>>> scattered throughout the source tree.\n>>> This restriction would need to deny fetch of the ITAR\n>>> documents yet allow fetch of any other files.\n>>>\n>>> Looking through the source code it would seem that\n>>> putting a hook call in the fetch-pack code would do it.\n>>\n>> I doubt it would make sense to put per-file permissions in Git\n>> as it doesn't version files but the complete state of a workspace.\n>> Even if you manage to hack the pack code to not include certain\n>> blobs when certain users ask for them, what would those users\n>> do when they want to create new commits based on commits where\n>> blobs are missing? Or would you send the protected blobs but\n>> replace their contents? Then Git would complain about that.\n>>\n>> However, both Gerrit Code Review and Gitolite offer per-branch\n>> permissions, so if it would be possible to put these files on\n>> branches of their own these tools would help.\n>\n> You pointed out some hurdles I'll have to think about\n> (blocked files not matching the SHA and so can't be committed).\n> \n> As to why I want to do this consider NSA non-export rules.\n> Our application would be built with NSA encryption\n> but we have foreign nationals working on the code\n> and so they are not permitted to see that part.\n> The makefiles look to see if the NSA encryption code file\n> is there and link it in. If not a stub is used.\n\nYou have to remember that with exception of submodules, which can be\nfetched or not, all operations between repositories operate on whole\ntree basis. The commit in Git (i.e. a single revision) always contain\n_all_ the files in repository (with exception of submodules).\n\nACL in e.g. Gitolite allow to refuse push if there are changes to\nspecified paths (per-file access control), but it wouldn't and\ncouldn't preent from viewing such \"restricted\" files.\n\n\n1. What you can do is manage two unrelated branches (without common\nancestor one orphan to the other), \"private\" and \"public\". You do\npublic work on branches starting on public branch, and merge both to\npublic and private, and you do private work on branches starting at\nprivate branch, and merge only to private. The public publishing\nrepository (e.g. on GitHub or repo.or.cz) would have only \"public\"\nbranch, while private clone (e.g. on intranet, or on private\nrepository on GitHub) would have both branches.\n\n2. Another solution that could work is to have stubs for \"restricted\"\nfiles, and in private repository use git-replace mechanism to replace\nthose stubs with \"restricted\" contents. Again in public publishing\nrepository you woldn't have refs/replace published, while in private\none you would have refs/replace and git would show \"restricted\"\ncontents replacing stubs. NOT TESTED!.\n\n3. As other wrote, you can have yet another solution: use submodules.\nYou would put \"restricted\" contents in submodule, and just not make\nrepository that makes submodule public. What would be visible would\nbe only SHA-1 of contents in supermodule. This assumes that you can\ndisentanle files into submodules (loose connection)...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"168038","messageId":"BANLkTikwEivOiQVV-B=g3pP_StXAa8CVwg@mail.gmail.com","threadId":"27365","inReplyTo":"4DD12517.1000308@bbn.com","subject":"Re: ACLs for GIT","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2011-05-17T01:32:29Z","receivedAt":"2011-05-17T01:32:29Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Mon, May 16, 2011 at 6:52 PM, Martin L Resnick wrote:\n> Thanks for the reply.\n>\n> But gitolite would only work to deny reads on a repository or ref basis\n> not a pathname level.\n\nI notice the original question has been answered, so this email is\njust for the record.\n\nGitolite does not do any access control on *read* access (fetch,\nclone). It can only do that on *write*s (push).\n\nGerrit does that because they've reimplemented git itself and have\ncoded that into their git engine somehow. I believe they had to\nimplement a callback from jgit to gerrit for the fetch, and deal with\nevil clients that might try to read an object by pushing a supposed\nchange on top of a SHA that they know but don't actually have. (Or\nsomething like that; I'm not real clear on this...).\n\nregards\n\nsitaram\n\nPS: Gitolite does have unreleased code to do this but it's a hack with\nseveral limitations. Gitolite makes a temp \"clone -l\", deletes all\nrefs from it that the user has no access to, then redirects the\ngit-upload-pack to that repo instead ;-)\n"},{"id":"168039","messageId":"BANLkTi=9vp+ibVa3tQzXbZSeYATKwmF60Q@mail.gmail.com","threadId":"27365","inReplyTo":"BANLkTikwEivOiQVV-B=g3pP_StXAa8CVwg@mail.gmail.com","subject":"Re: ACLs for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-05-17T01:49:08Z","receivedAt":"2011-05-17T01:49:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Mon, May 16, 2011 at 18:32, Sitaram Chamarty wrote:\n> On Mon, May 16, 2011 at 6:52 PM, Martin L Resnick wrote:\n>> Thanks for the reply.\n>>\n>> But gitolite would only work to deny reads on a repository or ref basis\n>> not a pathname level.\n>\n> I notice the original question has been answered, so this email is\n> just for the record.\n>\n> Gitolite does not do any access control on *read* access (fetch,\n> clone).  It can only do that on *write*s (push).\n>\n> Gerrit does that because they've reimplemented git itself and have\n> coded that into their git engine somehow.  I believe they had to\n> implement a callback from jgit to gerrit for the fetch,\n\nYes, we do.\n\n> and deal with\n> evil clients that might try to read an object by pushing a supposed\n> change on top of a SHA that they know but don't actually have. (Or\n> something like that; I'm not real clear on this...).\n\nYes, we also have protections for this. Users cannot push objects that\nreference objects they are not allowed to read. This check needs to be\ndone for delta bases as well as commit tree/parent pointers, and tree\nentries. Its not difficult, but its not as simple as just limiting the\nbranch names shown to upload-pack.\n\n> PS: Gitolite does have unreleased code to do this but it's a hack with\n> several limitations.  Gitolite makes a temp \"clone -l\", deletes all\n> refs from it that the user has no access to, then redirects the\n> git-upload-pack to that repo instead ;-)\n\nCute hack. Doesn't prevent the evil client from making an indirect\nreference to something you shouldn't have. :-)\n\n-- \nShawn.\n"},{"id":"168054","messageId":"BANLkTimPbQe7DGmR0VvDkU3=ZNjcAu7axw@mail.gmail.com","threadId":"27365","inReplyTo":"BANLkTi=9vp+ibVa3tQzXbZSeYATKwmF60Q@mail.gmail.com","subject":"Re: ACLs for GIT","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2011-05-17T12:08:11Z","receivedAt":"2011-05-17T12:08:11Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Tue, May 17, 2011 at 7:19 AM, Shawn Pearce wrote:\n> On Mon, May 16, 2011 at 18:32, Sitaram Chamarty wrote:\n\n>> PS: Gitolite does have unreleased code to do this but it's a hack with\n>> several limitations.  Gitolite makes a temp \"clone -l\", deletes all\n>> refs from it that the user has no access to, then redirects the\n>> git-upload-pack to that repo instead ;-)\n>\n> Cute hack. Doesn't prevent the evil client from making an indirect\n> reference to something you shouldn't have. :-)\n\nYou mean he constructs a commit that references a SHA he should not be\nhaving, pushes that to the branch he is allowed to read/write, then\npulls it down again to now really get that commit?\n\nYeah, I started writing a hook that looks at `rev-list\noldsha..newsha`, and for each commit run `git branch --contains SHA`\nand make sure it either (a) is totally new to the repo, ie no ref\ncontains this commit or (b) at least one of the refs that contains\nthis commit is allowed for this user.\n\nI haven't had time to do that though. Also, if there has been a\nrewind/force-push and the attacker knows the now unreachable SHA, this\nwould not catch it (it'd look like a totally new commit). That's a\nhard one.\n\nHaving two repos is still the best plan ;-)\n"},{"id":"168057","messageId":"BANLkTi=W2CtA2YaV_spru1E9pTWgoge3Kw@mail.gmail.com","threadId":"27365","inReplyTo":"BANLkTimPbQe7DGmR0VvDkU3=ZNjcAu7axw@mail.gmail.com","subject":"Re: ACLs for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-05-17T14:06:26Z","receivedAt":"2011-05-17T14:06:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, May 17, 2011 at 05:08, Sitaram Chamarty wrote:\n> On Tue, May 17, 2011 at 7:19 AM, Shawn Pearce wrote:\n>> On Mon, May 16, 2011 at 18:32, Sitaram Chamarty wrote:\n>\n>>> PS: Gitolite does have unreleased code to do this but it's a hack with\n>>> several limitations.  Gitolite makes a temp \"clone -l\", deletes all\n>>> refs from it that the user has no access to, then redirects the\n>>> git-upload-pack to that repo instead ;-)\n>>\n>> Cute hack. Doesn't prevent the evil client from making an indirect\n>> reference to something you shouldn't have. :-)\n>\n> You mean he constructs a commit that references a SHA he should not be\n> having, pushes that to the branch he is allowed to read/write, then\n> pulls it down again to now really get that commit?\n\nYes. Or, he has a SHA-1 he suspects is a tree or blob and lists that\nin a tree he pushes to a branch he can write to. Now he can fetch that\nbranch back, and obtain that object whose SHA-1 he has but whose\ncontents he does not have.\n\nThere is another attack that is incredibly improbable, but that JGit\ntries to protect against here as well. An evil user could try to push\nan object that uses the REF_DELTA format and specifies a SHA-1 base\nthat he wants to see at least some of the content of. The delta copy\ninstructions copy some of the base, and then insert content the\nattacker knows. In theory the attacker cannot predict the SHA-1 of the\nresulting object and thus cannot reference it in a tree or commit in\norder to make a link and fetch it back. However if there is a weakness\nin SHA-1 that has not been discovered yet an attacker may be able to\ncraft the text he knows and supplied as delta insert commands in such\na way that the text of the object he is trying to copy has little to\nno impact on the resulting SHA-1. Now he can predict the SHA-1 this\ndelta creates, and if he can make a link to it, he can fetch it back\nand acquire at least part of the remote object. Its paranoid to check\nthe REF_DELTA bases for visibility before applying the delta, but we\ndo it in JGit because its better to be slightly paranoid than to\nassume this theoretical attack is too improbable to succeed. (And it\nis given what we know about SHA-1 today.)\n\n> Yeah, I started writing a hook that looks at `rev-list\n> oldsha..newsha`, and for each commit run `git branch --contains SHA`\n> and make sure it either (a) is totally new to the repo, ie no ref\n> contains this commit or (b) at least one of the refs that contains\n> this commit is allowed for this user.\n\nYea, that isn't sufficient because of the tree/blob link issue. (See above.)\n\n> I haven't had time to do that though.  Also, if there has been a\n> rewind/force-push and the attacker knows the now unreachable SHA, this\n> would not catch it (it'd look like a totally new commit).  That's a\n> hard one.\n\nYes. This the branch --contains test is insufficient because you need\nto verify the \"new\" object actually was transmitted by the client in\nthis exchange, and wasn't just already present on disk. This is hard\nbecause in C Git unpack-objects will not write the object if the\nobject already exists, and then there is no list of objects the client\nsent. Again this is another area where JGit is paranoid. It keeps\ntrack of every object actually sent by the user. The only \"new\"\nobjects permitted are those that were sent by the user, any other\n\"new\" objects are attempts to access something the client shouldn't\nhave access to, or is a broken pack file created by a broken client\n(i.e. it did not send all objects it should have sent).\n\n> Having two repos is still the best plan ;-)\n\nYes, but tell that to Gerrit Code Review users. They really use the\nbranch ACL features. :-)\n\n-- \nShawn.\n"},{"id":"168068","messageId":"BANLkTik6dP9su_K5WxUYkcGUL76J5ObvMg@mail.gmail.com","threadId":"27365","inReplyTo":"BANLkTi=W2CtA2YaV_spru1E9pTWgoge3Kw@mail.gmail.com","subject":"Re: ACLs for GIT","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2011-05-17T15:41:44Z","receivedAt":"2011-05-17T15:41:44Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Tue, May 17, 2011 at 7:36 PM, Shawn Pearce wrote:\n> On Tue, May 17, 2011 at 05:08, Sitaram Chamarty wrote:\n\n> Yes. Or, he has a SHA-1 he suspects is a tree or blob and lists that\n> in a tree he pushes to a branch he can write to. Now he can fetch that\n> branch back, and obtain that object whose SHA-1 he has but whose\n> contents he does not have.\n\nGood point. Not too hard too I guess, unlike this one:\n\n> There is another attack that is incredibly improbable, but that JGit\n\n[snipped lots of complicated stuff]\n\n> assume this theoretical attack is too improbable to succeed. (And it\n> is given what we know about SHA-1 today.)\n\nIMO most of the theoretical attacks are just that. They advance the\nstate of the art but I've not heard of any of them actually being used\nin a real life scenario. The sad fact is there are much weaker links\nto be found if you look around and you don't need all this.\n\n>> Having two repos is still the best plan ;-)\n>\n> Yes, but tell that to Gerrit Code Review users. They really use the\n> branch ACL features. :-)\n\nInteresting. I do a fair amount of git consulting and training\n(inhouse) and this has only come up once so far. I haven't seen it as\nbeing that common at all.\n"}]}