git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin L Resnick <mresnick@bbn.com>
To: "Magnus Bäck" <magnus.back@sonyericsson.com>
Cc: git@vger.kernel.org
Subject: Re: ACLs for GIT
Date: Mon, 16 May 2011 09:22:21 -0400	[thread overview]
Message-ID: <4DD1250D.50005@bbn.com> (raw)
In-Reply-To: <20110515201513.GA27758@jpl.local>

Thanks Mangus.

You pointed out some hurdles I'll have to think about
(blocked files not matching the SHA and so can't be committed).

As to why I want to do this consider NSA non-export rules.
Our application would be built with NSA encryption
but we have foreign nationals working on the code
and so they are not permitted to see that part.
The makefiles look to see if the NSA encryption code file
is there and link it in. If not a stub is used.


On 05/15/2011 04:15 PM, Magnus Bäck wrote:
> On Sunday, May 15, 2011 at 21:24 CEST,
>       Martin L Resnick<mresnick@bbn.com>  wrote:
>
>> Is anyone working on adding access control to GIT ?
>>
>> I'm looking for the Subversion equivalent of mod_authz_svn.
>> I need to restrict read access of ITAR documents that are
>> scattered throughout the source tree.
>> This restriction would need to deny fetch of the ITAR
>> documents yet allow fetch of any other files.
>>
>> Looking through the source code it would seem that
>> putting a hook call in the fetch-pack code would do it.
>
> I doubt it would make sense to put per-file permissions in Git
> as it doesn't version files but the complete state of a workspace.
> Even if you manage to hack the pack code to not include certain
> blobs when certain users ask for them, what would those users
> do when they want to create new commits based on commits where
> blobs are missing? Or would you send the protected blobs but
> replace their contents? Then Git would complain about that.
>
> However, both Gerrit Code Review and Gitolite offer per-branch
> permissions, so if it would be possible to put these files on
> branches of their own these tools would help.
>

  reply	other threads:[~2011-05-16 14:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-15 19:24 ACLs for GIT Martin L Resnick
2011-05-15 20:15 ` Magnus Bäck
2011-05-16 13:22   ` Martin L Resnick [this message]
2011-05-16 15:26     ` Richard Peterson
2011-05-16 15:33     ` Phil Hord
2011-05-16 15:36       ` Martin L Resnick
2011-05-16 16:28     ` Jakub Narebski
2011-05-15 20:16 ` R. Tyler Croy
2011-05-16 13:22   ` Martin L Resnick
2011-05-17  1:32     ` Sitaram Chamarty
2011-05-17  1:49       ` Shawn Pearce
2011-05-17 12:08         ` Sitaram Chamarty
2011-05-17 14:06           ` Shawn Pearce
2011-05-17 15:41             ` Sitaram Chamarty
2011-05-15 20:28 ` Marc Weber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DD1250D.50005@bbn.com \
    --to=mresnick@bbn.com \
    --cc=git@vger.kernel.org \
    --cc=magnus.back@sonyericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).