On Wed, Apr 03, 2013 at 09:51:38AM -0400, C. Michael Pilato wrote:
> On 04/03/2013 07:04 AM, Stefan Sperling wrote:
> > - prevent control characters from entering filenames at the repos layer
>
> +0 (It's a bit overly conservative, probably, but at this layer of the API
> I'm less grumpy about that fact.)
Well, the argument goes like this:
Subversion cannot handle \n in filenames at many levels.
It was found that the FSFS layer cannot handle it without repository
corruption, and it was pointed out that e.g. the unidiff format and the
Subversion dump file format have problems with \n in filenames, too.
So preventing filenames with \n in Subversion in general seems to be
a good thing to do. Since only FSFS currently rejects \n, BDB users
are left unprotected from harmful effects of \n outside the filesystem
layer unless we make the BDB layer reject such paths as well (which you
don't agree with) or make the repos layer reject such paths (which it
does as of r1461760 and which we should backport IMO).
Next, others have pointed out that similar issues can be caused by
other control characters (such as \r) on some platforms, and also
that libsvn_client has always been rejecting paths which contain any
control characters. Consistency is a good thing, and making Subversion
servers forbid control characters in filenames outright addresses our
concerns about \n as well.
Does that make sense?
FWIW, I'm unhappy with the fact that we keep pretending the FS API was
somehow special while today, for all practical purposes, it is not.
I agree with Ben that the FS API should be considered an integral part
of Subversion and should mirror constraints we build into the system
in a consistent way because that makes Subversion easier to maintain
in the long run and might prevent some classes of security and data
corruption issues (such as the one that started this thread).
But I can live with the current solution and respect the goals the FS API
designers envisioned, and which the FSFS design failed to deliver, as
long as the repos layer ensures that none of our users will run into
nasty problems with control characters in filenames in the future.
Received on 2013-04-03 16:25:56 CEST