[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Betr.: RE: Betr.: RE: Questions about svn:externals

From: Jan Keirse <jan.keirse_at_tvh.be>
Date: Thu, 20 Jan 2011 10:41:57 +0100

 David Aldrich <David.Aldrich_at_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."
Received on 2011-01-20 10:41:14 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.