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

RE: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk

From: Bert Huijben <bert_at_vmoo.com>
Date: Thu, 19 Aug 2010 21:15:59 -0700

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: donderdag 19 augustus 2010 13:30
> To: Ramkumar Ramachandra
> Cc: users_at_subversion.apache.org
> Subject: Re: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk
> On Thu, Aug 19, 2010 at 08:02:02PM +0000, Ramkumar Ramachandra wrote:
> > Feldhacker, Chris <Feldhacker.Chris <at> principal.com> writes:
> > > Remote "dump" makes sense -- and I assume everything being dumped
> is
> > subject to the authorization/access
> > > control restrictions that have
> > been put into place on the server, yes? (A particular path or file
> > won't be
> > > included in the dump if the user doesn't have permission to
> > access it, right?)
> >
> > Exactly. Since svnrdump works purely on the RA layer, authz should be
> > taken care of for free.
> Have you tested this?

No.. but this has been tested for svnsync, when the replay functionality was

And besides how would the client be able to obtain the security settings
from the server, to apply them on the client?... To make sure that no client
can get access to files that it isn't supposed to?

I don't think it makes sense to even think about this. If there would be a
problem, it would be in the server side implementation of the replay api,
which is available since at least 1.5. And that would be a huge security
problem for all existing servers even without svnrdump.

So, while you might want to see an additional security review for the
existing replay api (Why not the other apis then?), I don't think it makes
sense to hold svnrdump on it. It only uses existing apis for obtaining the
data, nothing new.

And even if we would find an issue anybody can compile the current version
(which just uses public apis), so the entire server security would already
be broken.

Received on 2010-08-20 06:17:31 CEST

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.