On Fri, Oct 18, 2013 at 6:38 PM, C. Michael Pilato <cmpilato_at_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_at_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.
Received on 2013-10-20 22:53:17 CEST