Re: Authz on Collection of Repositories (was: Expansion of authz policy name leak)

2012-10-25 Thread Thomas Åkesson

On 24 okt 2012, at 15:37, Roderich Schupp wrote:

> On Wed, Oct 24, 2012 at 6:09 AM, Daniel Shahaf  
> wrote:
>> Daniel Shahaf wrote on Wed, Oct 24, 2012 at 06:07:45 +0200:
>>> I can't reproduce this.  'curl -s https://svn.apache.org/repos/private/'
>> Since I didn't pass -u, in both cases I was browsing as an anonymous user.
>>> That server runs 1.7.0.
> 
> SVN 1.7.7 here and I tested as an authenticated user (
> does "require valid-user"). I'm not listed in the
> AuthzSVNAccessFile and it doesn't contain any * or $special rules either.

I was able to reproduce after reconfiguring from SVNParentPath to SVNPath.
- With Satisfy All (default): curl -s http://... -u username
- With Satisfy Any: curl -s http://...

Got similar output to what Roderich posted when authz configured such that user 
has no access.

If this behaviour appeared in SVN 1.7, then it seems likely that we are seeing 
another side effect of the very change that this thread started from: i.e. the 
"fix" for issue 2753. That fix presumably removes authz when accessing "/" 
regardless whether that means the list of repositories or the root of a single 
repository.

At minimum, this should be changed such that removal of authz on "/" only 
applies if referring to actual server root. That would enable hosting 
SVNParentPath directly on server root while reverting to 1.6 authz for the 
other cases: SVNParentPath in /somepath/  and SVNPath configs. Somewhat half 
baked since the "leak" will remain when hosting SVNParentPath directly on 
server root but ok for other configs.

A better solution is the earlier suggestion to filter list of repositories 
based on actual access to the individual repositories. That would remove the 
non-obvious behaviours which is somewhat important with authz.

regards,
Thomas Å. 

Re: [Subversion Wiki] Update of "FS2_Design" by brane

2012-10-25 Thread Daniel Shahaf
Branko Čibej wrote on Thu, Oct 25, 2012 at 05:25:05 +0100:
> On 25.10.2012 05:17, Hyrum K Wright wrote:
> > On Wed, Oct 24, 2012 at 11:25 PM, Apache subversion Wiki
> >  wrote:
> >> Dear Wiki user,
> >>
> >> You have subscribed to a wiki page or wiki category on "Subversion Wiki" 
> >> for change notification.
> >>
> >> The "FS2_Design" page has been changed by brane:
> >> http://wiki.apache.org/subversion/FS2_Design?action=diff&rev1=2&rev2=3
> >>
> >> Comment:
> >> Describe versioned filesystem concepts.
> >>
> >>   = The Versioned Filesystem =
> >>
> >> + Subversion's versioned filesystem is a set of snapshots of the state of 
> >> a tree of nodes. Changes to the tree are described by ''transactions'', 
> >> which are a set of mutations of the tree state. Discrete states of the 
> >> tree are called ''revisions'' and are represented by immutable 
> >> transactions. Each snapshot (except for the first, which has none and is 
> >> called ''revision 0'') has exactly one predecessor and at most one 
> >> immutable successor. Any number of mutable transactions can exist at the 
> >> same time. The set of revisions is a temporally ordered sequence; the last 
> >> or ''youngest'' revision is called the ''HEAD''. New revisions are created 
> >> by ''merging'' the changes described by a mutable transaction with the 
> >> tree state represented by HEAD and appending the resulting revision to the 
> >> sequence, creating a new HEAD.
> >> +
> >> + [[attachment:vfs-snapshot-sequence.svg]]
> > This might be more helpful if it was an image type the wiki could
> > embed.  When I went to the page, it didn't want to show me the image.
> 
> Yes. Apparently the ASF's version of Moinmoin doesn't like SVG images
> (treats them as binary blobs...), even though Moinmoin itself should
> support them. I'll upload a PNG, but also bug infra about enabling
> embedded SVG images.

Let me know if I can help...


svn_delta_path_driver deprecation

2012-10-25 Thread Stefan Fuhrmann
Hi,

We've managed to widely eliminate the use of deprecated
functions except for a few cases. One of them is
svn_delta_path_driver.

The problem is that svn_delta_path_driver2 requires an
ordered path array as input that none but one of the callers
can actually provide. We would need to sort the path list
for all other callers via some copy-n-paste code.

It seems that we can't easily check a given path array
for being properly ordered inside svn_delta_path_driver2,
so I'd like to add a flag parameter that tells the function
whether it needs to sort the array before using it. Alternatively,
we could add a some __compare_fn_t as a parameter.
If NULL, assume ordered input, otherwise sort using
the order defined by the compare function.

Any other ideas?

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*


Re: [Subversion Wiki] Update of "FS2_Design" by brane

2012-10-25 Thread Branko Čibej
On 25.10.2012 17:41, Daniel Shahaf wrote:
> Branko Čibej wrote on Thu, Oct 25, 2012 at 05:25:05 +0100:
>> On 25.10.2012 05:17, Hyrum K Wright wrote:
>>> On Wed, Oct 24, 2012 at 11:25 PM, Apache subversion Wiki
>>>  wrote:
 Dear Wiki user,

 You have subscribed to a wiki page or wiki category on "Subversion Wiki" 
 for change notification.

 The "FS2_Design" page has been changed by brane:
 http://wiki.apache.org/subversion/FS2_Design?action=diff&rev1=2&rev2=3

 Comment:
 Describe versioned filesystem concepts.

   = The Versioned Filesystem =

 + Subversion's versioned filesystem is a set of snapshots of the state of 
 a tree of nodes. Changes to the tree are described by ''transactions'', 
 which are a set of mutations of the tree state. Discrete states of the 
 tree are called ''revisions'' and are represented by immutable 
 transactions. Each snapshot (except for the first, which has none and is 
 called ''revision 0'') has exactly one predecessor and at most one 
 immutable successor. Any number of mutable transactions can exist at the 
 same time. The set of revisions is a temporally ordered sequence; the last 
 or ''youngest'' revision is called the ''HEAD''. New revisions are created 
 by ''merging'' the changes described by a mutable transaction with the 
 tree state represented by HEAD and appending the resulting revision to the 
 sequence, creating a new HEAD.
 +
 + [[attachment:vfs-snapshot-sequence.svg]]
>>> This might be more helpful if it was an image type the wiki could
>>> embed.  When I went to the page, it didn't want to show me the image.
>> Yes. Apparently the ASF's version of Moinmoin doesn't like SVG images
>> (treats them as binary blobs...), even though Moinmoin itself should
>> support them. I'll upload a PNG, but also bug infra about enabling
>> embedded SVG images.
> Let me know if I can help...

It's INFRA-5451

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download



Re: svn_delta_path_driver deprecation

2012-10-25 Thread C. Michael Pilato
On 10/25/2012 01:02 PM, Stefan Fuhrmann wrote:
> Hi,
> 
> We've managed to widely eliminate the use of deprecated
> functions except for a few cases. One of them is
> svn_delta_path_driver.
> 
> The problem is that svn_delta_path_driver2 requires an
> ordered path array as input that none but one of the callers
> can actually provide. We would need to sort the path list
> for all other callers via some copy-n-paste code.
> 
> It seems that we can't easily check a given path array
> for being properly ordered inside svn_delta_path_driver2,
> so I'd like to add a flag parameter that tells the function
> whether it needs to sort the array before using it. Alternatively,
> we could add a some __compare_fn_t as a parameter.
> If NULL, assume ordered input, otherwise sort using
> the order defined by the compare function.
> 
> Any other ideas?

Would that sorting function ever be anything besides NULL or the wrapper
around svn_path_compare_paths()?  I mean, "depth-first sorting" has a pretty
specific definition where driving an Ev1 editor is concerned, so ... seems a
boolean sort-the-paths-for-me-please parameter is the more sensible provision.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature


Drive-by build warning notification.

2012-10-25 Thread C. Michael Pilato
Seeing this build warning.  Can't recall seeing it in the past.

{{{
subversion/svnserve/cyrus_auth.c:101:3: warning: initialization from in\
compatible pointer type [enabled by default]
subversion/svnserve/cyrus_auth.c:101:3: warning: (near initialization f\
or ‘callbacks[0].proc’) [enabled by default]
}}}

Code in question is here:

{{{

static sasl_callback_t callbacks[] =
{
  { SASL_CB_CANON_USER, canonicalize_username, NULL },
  { SASL_CB_LIST_END, NULL, NULL }
};

}}}

No time to investigate, but didn't want to overlook and/or forget.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature