Ben Reser wrote on Tue, Mar 26, 2013 at 09:06:56 -0700:
> On Tue, Mar 26, 2013 at 6:36 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > We should add some C tests as well to verify API behaviour at the
> > client layer and at the repos layer.
> >
> > Given the ripple effects of this problem in FSFS revision files I think
> > we should ensure that the Subversion server blocks such filenames from
> > entering the repository (any repository, FSFS and BDB). It seems FSFS format
> > changes would be required to support filenames with trailing newlines
> > properly, an effort which isn't worth the gain in my opinion.
>
> +1, this is not an allowed use and is obviously a hole in our server
> implementations. I'd actually say this is a potential DoS since
> committing such a file creates all sorts of havoc for clients and
> admins after the fact.
>
I'd call it a DoS if you can commit such a file and can't later 'svn rm
URL' it.
> > And given the ripple effects seen in areas such as repository verification,
> > svnsync, and ra_neon, I don't think we can afford to call this a supported
> > use case until all components of the system have been fixed to handle
> > filenames with trailing newlines properly.
>
> It probably breaks other things like the dump format and diff. Tons
> of things assume newline has special meaning.
Fortunately we could encode newlines the same way in FSFS revision
files, diff, and dumpfile headers. (Just need a new service routine
(dare I say yet another svn_foo_canonicalize() function? :-)))
Or we could forbid newlines in pathnames. The only problem with that is
that the 1.0 API promised they would work... but if no one uses that,
I'd be fine with calling it an erratum and disallowing it henceforth.
Received on 2013-03-26 17:11:12 CET