subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c libsvn_ra_svn/client.c
Date Sun, 20 Oct 2013 20:52:36 GMT
On Fri, Oct 18, 2013 at 6:38 PM, C. Michael Pilato <cmpilato@collab.net>wrote:

> On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote:
> > On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <bert@qqmail.nl
> >     Then most likely there is a difference between implementation and
> >     documentation
> >
> >     svn ls -R path
> >
> >     will use this function with deeper names.
> >
> >     See list.c get_dir_contents(), which calls itself recursively with
> >     longer and longer components.
> >
> >     And I'm pretty sure there are also third party clients that use this
> >     feature via their own usage of the ra layer.
> >
> >
> > That's what I originally thought as well. As it turns out,
> > the path gets combined above the RA layer in lib_client.
> >
> > I spent most of today figuring out why svn ls -R left
> > my laptop idle (see r1533530), so I had exactly the
> > use-case that you described.
>
> Bert, are you perhaps thinking of the *input* to svn_ra_get_dir(), which
> accepts a path relative to the session URL that can have an arbitrary
> number of components?
>
> Stefan is correct that -- at least in the case of our own libraries --
> the "name" parsed from the get-dir *response* should only be a single
> path component.  (Its source is the svn_fs_dir_entries hash keys, which
> are single-component relpaths.)
>
> That said, Stefan, we made a conscious decision to sanitize paths on
> both sides of the wire because we don't control the wire itself.  For
> example, your libsvn_ra_svn-wielding client might not be talking to
> 'svnserve', but to a third-party custom implementation of the Subversion
> server that speaks the 'svn' protocol.  As such, there is an opportunity
> for malformed data to be returned, and the canonicalization protects our
> client (to a degree) from certain potentially problems there.  If
> anything, an additional check should be *added* at that call site to
> verify that 'name' is, in fact, but a single path component.
>

This function does not receive paths. It is basically reading a
directory hash and the incoming names must be file / directory
names. r1533812 adds a check for that error condition.

-- Stefan^2.

Mime
View raw message