You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2007/08/28 19:52:40 UTC

New log/blame -g option and authz rules

Hyrum,

Was having an email discussion internally at CollabNet and the
question was asked whether the new log -g and blame -g options respect
authz rules?  I imagine we have some rules/standards as to whether you
are allowed to know the kind of details about a revision these options
expose.  So not sure if there is an issue here or not.

I can file an issue in the issue tracker if you have either not
thought about it, or would like a place to record an answer for
posterity.

Of course, I do not mean to direct this question to just you.  Anyone
is free to jump in with opinions or answers.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New log/blame -g option and authz rules

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> Hyrum,
> 
> Was having an email discussion internally at CollabNet and the
> question was asked whether the new log -g and blame -g options respect
> authz rules?  I imagine we have some rules/standards as to whether you
> are allowed to know the kind of details about a revision these options
> expose.  So not sure if there is an issue here or not.
> 
> I can file an issue in the issue tracker if you have either not
> thought about it, or would like a place to record an answer for
> posterity.
> 
> Of course, I do not mean to direct this question to just you.  Anyone
> is free to jump in with opinions or answers.
> 

My feeling is that we should honor authz rules when tracing ancestry for
'log -g' and 'blame -g'.  I believe that the current implementation does
do appropriate authz checking, but I haven't tested it thoroughly.  We
should probably file an issue to ensure that this gets done before 1.5
is released.  Additional tests are welcome.

Also, I'm in the process of reevaluating the way that we iterate over
merge history (think something like svn_repos__walk_ancestry() ), and
may have some additional ideas about this topic as I get deeper into it.
 If people have additional insight, I'm very much open to it.

-Hyrum

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org