You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Keirse <ja...@tvh.be> on 2011/01/19 10:58:24 UTC
Betr.: RE: Questions about svn:externals
David Aldrich <Da...@EU.NEC.COM> schreef op 19/01/2011 10:42:15:
> Hi
>
> I'd like to explain my high level problem, which I hoped externals
> would solve. Maybe someone will have a suggestion how to properly
> address this.
>
> Our source code is used by several developer groups. A few files
> need to be confidential to one group. We can set access permissions
> on these files in the trunk using Apache to support this. However,
> if a member of that privileged group branches or tags the trunk,
> those files will get copied to the new branch/tag and be visible to
> all. Subversion can't copy the permission structure across. This
> provides a maintenance headache.
>
> So I thought we could put the confidential files in another repo and
> set appropriate permissions there. The main project will bring those
> few files in and the access permissions of the source repo will
> always be imposed wherever the external appears.
>
> But this is not really what externals are meant for, so I feel
> unhappy about this solution. Furthermore, it seems best to always
> make externals use fixed revisions, which isn't what we would want
> as those confidential files will be continually changing.
>
> Please can anyone suggest a better way of solving this problem?
In the future hopefully an authz file with wildcards will solve the
problem:
http://subversion.tigris.org/issues/show_bug.cgi?id=2662
Right now I don't there's anything better than externals.
Kind Regards,
JAN KEIRSE
ICT-DEPARTMENT
Software quality & Systems: Software Engineer
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."
RE: Betr.: RE: Questions about svn:externals
Posted by David Aldrich <Da...@EU.NEC.COM>.
Hi Jan
> In the future hopefully an authz file with wildcards will solve the
> problem:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2662
>
> Right now I don't there's anything better than externals.
Thanks, I think that this is what we need. However, I can't see this on the svn roadmap. Does anyone know if this feature is progressing?
BR
David
Re: Betr.: RE: Betr.: RE: Questions about svn:externals
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Thu, Jan 20, 2011 at 13:40:49 +0100:
> If someone decides to put a lot of effort in this for a custom
> solution, you may want to consider another option: to take a good look
> at issue http://subversion.tigris.org/issues/show_bug.cgi?id=2662
> (authz with wildcards), and try to bring it home.
>
> This feature is not impossible, it's just that someone has to take the
> time to drive it to completion. Read up on the issue and the comments
> that are listed therein, and take a look at the patches that have been
> proposed. Maybe someone can take a fresh look at those patches, clean
> them up, and start a discussion on the dev-list to get the thing
> reviewed in detail, and maybe added to svn core ...
Before anyone starts reviewing patches, though, it's better --- on
issues of this scale --- to stop and review the design first. i.e.,
review "What's going to be done" before "How it's being done".
(maybe the referred threads already did some of that analysis)
Re: Betr.: RE: Betr.: RE: Questions about svn:externals
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jan 20, 2011 at 10:41 AM, Jan Keirse <ja...@tvh.be> wrote:
> David Aldrich <Da...@EU.NEC.COM> schreef op 20/01/2011 10:24:28:
>
>> Hi Jan
>>
>> > I've changed my mind, there is something that may be better than
>> > externals, although it requires a little trick.
>> > You should be able to create a commit hook that checks if the authz
> file
>> > reflects the restrictions you want on a specific folder
>> > (*/thesecretfolder/*) for the branch
>> > (/branches/somebranch/thesecretfolder) and if not add the
> restrictions.
>>
>> I get your drift but may I check I am understanding you correctly?
>>
>> The authz file would contain:
>>
>> */thesecretfolder/*
>> @privileged_group = rw
>> * =
>>
>> svn does not expand wildcards in authz but I guess it will not
>> complain about such an entry. The hook reads authz and does the
>> comparison of the actual commit path against this wildcard path
>> using regular expressions (or whatever). Am I right so far?
>
> No, that would not stop read access. What I wanted to say is that if you
> commit a file a commit hook checks if it's path indicates it should be
> mentioned in the authz file (because for example the path contains a
> foldername thesecretfolder) and if it finds such folder and does not find
> an entry for it in authz file it adds the folder to the authz file.
> If a developer branches trunk to branches/myexperiment the commit hook
> will fire and detect the new branch and adjust permissions to the secret
> folder in the authz file. (add /branches/myexperiment/thesecretfolder.)
> This would avoid accidents. The only thing it would not catch is if a
> developer deliberately branches /trunk/yourproject/yoursecretfolder to
> /branches/makethesecretpublic, but off course if you don't trust your
> developers not to do that you'd better not give them access to the code in
> the first place because there would be smarter ways to deliberately
> publish a company secret (methods that are not so easy to track back to
> the offender.)
>
>>
>> The hook must then check that the committer has rights to commit to
>> that path. So the hook uses the access permission specification in
>> the above entry, and checks that the committer belongs to
>> 'privileged_group'. Then the hook allows or blocks the commit. Am I
> correct?
>
> As said above that would stop commits but not checkout. I don't think
> there's a pre-checkout hook.
>
>> > The advantage of this approach over externals is that you'll have
> atomic
>> > commits, the version of the 'secretfolder' will be linked to the
> versions
>> > in the rest of the repository,... And if one day the suggested
> wildcard
>> > feature is implemented all you'll have to do is update the authz file
> to
>> > contain a wildcard, remove the commit hook and you're done.
>>
>> Yes, I like your idea, thanks. I am quite opposed to using externals
>> for this since I realised that externals are not well supported in
>> branching and merging.
>>
>> I did think of another approach before receiving your suggestion. I
>> thought of having a proprietary 'my_authz' file which allows
>> wildcards. Then our own mangler would check what branches exist,
>> read our my_authz and generate a real authz file with all the
>> necessary expanded paths and permissions. Could be run regularly by
>> cron (or whatever).
>
> My suggestion is basically doing this but not with cron, but in the commit
> hook. If you do it with cron you'd have a small window where the data
> would be public.
>
>> However, your suggestion is more elegant. Not sure which would be
>> more efficient.
If someone decides to put a lot of effort in this for a custom
solution, you may want to consider another option: to take a good look
at issue http://subversion.tigris.org/issues/show_bug.cgi?id=2662
(authz with wildcards), and try to bring it home.
This feature is not impossible, it's just that someone has to take the
time to drive it to completion. Read up on the issue and the comments
that are listed therein, and take a look at the patches that have been
proposed. Maybe someone can take a fresh look at those patches, clean
them up, and start a discussion on the dev-list to get the thing
reviewed in detail, and maybe added to svn core ...
(I am not hindered by any detailed knowledge about this issue, just
thinking in general terms here)
Cheers,
--
Johan
Betr.: RE: Betr.: RE: Questions about svn:externals
Posted by Jan Keirse <ja...@tvh.be>.
David Aldrich <Da...@EU.NEC.COM> schreef op 20/01/2011 10:24:28:
> Hi Jan
>
> > I've changed my mind, there is something that may be better than
> > externals, although it requires a little trick.
> > You should be able to create a commit hook that checks if the authz
file
> > reflects the restrictions you want on a specific folder
> > (*/thesecretfolder/*) for the branch
> > (/branches/somebranch/thesecretfolder) and if not add the
restrictions.
>
> I get your drift but may I check I am understanding you correctly?
>
> The authz file would contain:
>
> */thesecretfolder/*
> @privileged_group = rw
> * =
>
> svn does not expand wildcards in authz but I guess it will not
> complain about such an entry. The hook reads authz and does the
> comparison of the actual commit path against this wildcard path
> using regular expressions (or whatever). Am I right so far?
No, that would not stop read access. What I wanted to say is that if you
commit a file a commit hook checks if it's path indicates it should be
mentioned in the authz file (because for example the path contains a
foldername thesecretfolder) and if it finds such folder and does not find
an entry for it in authz file it adds the folder to the authz file.
If a developer branches trunk to branches/myexperiment the commit hook
will fire and detect the new branch and adjust permissions to the secret
folder in the authz file. (add /branches/myexperiment/thesecretfolder.)
This would avoid accidents. The only thing it would not catch is if a
developer deliberately branches /trunk/yourproject/yoursecretfolder to
/branches/makethesecretpublic, but off course if you don't trust your
developers not to do that you'd better not give them access to the code in
the first place because there would be smarter ways to deliberately
publish a company secret (methods that are not so easy to track back to
the offender.)
>
> The hook must then check that the committer has rights to commit to
> that path. So the hook uses the access permission specification in
> the above entry, and checks that the committer belongs to
> 'privileged_group'. Then the hook allows or blocks the commit. Am I
correct?
As said above that would stop commits but not checkout. I don't think
there's a pre-checkout hook.
> > The advantage of this approach over externals is that you'll have
atomic
> > commits, the version of the 'secretfolder' will be linked to the
versions
> > in the rest of the repository,... And if one day the suggested
wildcard
> > feature is implemented all you'll have to do is update the authz file
to
> > contain a wildcard, remove the commit hook and you're done.
>
> Yes, I like your idea, thanks. I am quite opposed to using externals
> for this since I realised that externals are not well supported in
> branching and merging.
>
> I did think of another approach before receiving your suggestion. I
> thought of having a proprietary 'my_authz' file which allows
> wildcards. Then our own mangler would check what branches exist,
> read our my_authz and generate a real authz file with all the
> necessary expanded paths and permissions. Could be run regularly by
> cron (or whatever).
My suggestion is basically doing this but not with cron, but in the commit
hook. If you do it with cron you'd have a small window where the data
would be public.
> However, your suggestion is more elegant. Not sure which would be
> more efficient.
Kind Regards,
JAN KEIRSE
ICT-DEPARTMENT
Software quality & Systems: Software Engineer
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."
RE: Betr.: RE: Questions about svn:externals
Posted by David Aldrich <Da...@EU.NEC.COM>.
Hi Jan
> I've changed my mind, there is something that may be better than
> externals, although it requires a little trick.
> You should be able to create a commit hook that checks if the authz file
> reflects the restrictions you want on a specific folder
> (*/thesecretfolder/*) for the branch
> (/branches/somebranch/thesecretfolder) and if not add the restrictions.
I get your drift but may I check I am understanding you correctly?
The authz file would contain:
*/thesecretfolder/*
@privileged_group = rw
* =
svn does not expand wildcards in authz but I guess it will not complain about such an entry. The hook reads authz and does the comparison of the actual commit path against this wildcard path using regular expressions (or whatever). Am I right so far?
The hook must then check that the committer has rights to commit to that path. So the hook uses the access permission specification in the above entry, and checks that the committer belongs to 'privileged_group'. Then the hook allows or blocks the commit. Am I correct?
> The advantage of this approach over externals is that you'll have atomic
> commits, the version of the 'secretfolder' will be linked to the versions
> in the rest of the repository,... And if one day the suggested wildcard
> feature is implemented all you'll have to do is update the authz file to
> contain a wildcard, remove the commit hook and you're done.
Yes, I like your idea, thanks. I am quite opposed to using externals for this since I realised that externals are not well supported in branching and merging.
I did think of another approach before receiving your suggestion. I thought of having a proprietary 'my_authz' file which allows wildcards. Then our own mangler would check what branches exist, read our my_authz and generate a real authz file with all the necessary expanded paths and permissions. Could be run regularly by cron (or whatever).
However, your suggestion is more elegant. Not sure which would be more efficient.
BR
David
Betr.: RE: Questions about svn:externals
Posted by Jan Keirse <ja...@tvh.be>.
Jan Keirse <ja...@tvh.be> schreef op 19/01/2011 10:58:24:
> David Aldrich <Da...@EU.NEC.COM> schreef op 19/01/2011 10:42:15:
>
> > Hi
> >
> > I'd like to explain my high level problem, which I hoped externals
> > would solve. Maybe someone will have a suggestion how to properly
> > address this.
> >
> > Our source code is used by several developer groups. A few files
> > need to be confidential to one group. We can set access permissions
> > on these files in the trunk using Apache to support this. However,
> > if a member of that privileged group branches or tags the trunk,
> > those files will get copied to the new branch/tag and be visible to
> > all. Subversion can't copy the permission structure across. This
> > provides a maintenance headache.
> >
> > So I thought we could put the confidential files in another repo and
> > set appropriate permissions there. The main project will bring those
> > few files in and the access permissions of the source repo will
> > always be imposed wherever the external appears.
> >
> > But this is not really what externals are meant for, so I feel
> > unhappy about this solution. Furthermore, it seems best to always
> > make externals use fixed revisions, which isn't what we would want
> > as those confidential files will be continually changing.
> >
> > Please can anyone suggest a better way of solving this problem?
>
> In the future hopefully an authz file with wildcards will solve the
> problem:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2662
>
> Right now I don't there's anything better than externals.
I've changed my mind, there is something that may be better than
externals, although it requires a little trick.
You should be able to create a commit hook that checks if the authz file
reflects the restrictions you want on a specific folder
(*/thesecretfolder/*) for the branch
(/branches/somebranch/thesecretfolder) and if not add the restrictions.
The advantage of this approach over externals is that you'll have atomic
commits, the version of the 'secretfolder' will be linked to the versions
in the rest of the repository,... And if one day the suggested wildcard
feature is implemented all you'll have to do is update the authz file to
contain a wildcard, remove the commit hook and you're done.
Kind Regards,
JAN KEIRSE
ICT-DEPARTMENT
Software quality & Systems: Software Engineer
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."