C. Michael Pilato wrote on Wed, 17 Sep 2008 at 11:05 -0400:
> Daniel Shahaf wrote:
> > But, in this case, when *should* svn_path_check_valid() be used? Why
> > does it check for control characters -- which of its callers need this
> > check?
>
Thanks for the long explanation -- but it answers a lot more than I asked;
I really only tried to understand why it disallowed just control
characters and not other things (e.g., why it chose not to forbid colons
in filenames). I already understood the "FS allows more than higher
layers allow" point.
Thanks,
Daniel
> There are two different set of requirements in the mix here.
>
> libsvn_fs doesn't care about control characters, nor does it have any reason
> to. It's just a versioned filesystem, right? It doesn't have hooks, or
> print output, or speak XML. In fact, it doesn't use the paths provided it
> in any way that doesn't involve its own virtual storage system. The only
> reason it has the one little can't-have-a-null-byte rule is because without
> it we couldn't pass C strings around, and custom counted strings would be a
> drag to maintain.
>
> The *rest* of Subversion cares, though. You can't pass control characters
> over our XML WebDAV reports. You can't store them in XML .svn/entries files
> (back when we had such). They look ugly in screen output. That's why the
> Subversion *client* layers protect against such things. And, arguably,
> mod_dav_svn and svnserve (as entry points to the Subversion system) should
> be performing similar checks of their network input.
>
> This duality has always existed in Subversion, and it makes perfect sense.
> That's the beauty of modularized code and solid APIs. Sure, you can use the
> FS APIs to inject paths into your filesystem that the rest of Subversion
> will croak on, but that's an understood risk. What we want to disallow are:
>
> * Using the FS APIs to introduce paths that violate the FS constraints
>
> * Using higher-level Subversion access points to introduce paths that
> violate the requirements of those higher-level Subversion layers.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-17 18:19:33 CEST