On Tue, Mar 26, 2013 at 8:40 PM, C. Michael Pilato <cmpil...@collab.net> wrote:
> On 03/26/2013 12:10 PM, Daniel Shahaf wrote:
>> 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.
>
> I'm very much in the "let libsvn_fs do everything it can, and let
> libsvn_repos enforce Subversion-specific requirements" camp.
>
> Certainly, libsvn_repos should be disallowing newline-bearing paths. We
> weren't able to support these paths when our .svn/entries file was
> plaintext, we've never been able to support them in our dump format (which
> is a libsvn_repos construct), and so on.
>
> I'm not so sure about libsvn_fs. BDB should be able to handle them just
> fine, but it sounds like FSFS can't. Do we just make a post-facto
> declaration that, going forward, we won't try to support these paths in the
> FS layer?
>
We already have svn_fs__path_valid() and validate all incoming FS
paths in fs-loader.c. Current svn_fs__path_valid() implementation is:
[[[
svn_error_t *
svn_fs__path_valid(const char *path, apr_pool_t *pool)
{
/* UTF-8 encoded string without NULs. */
if (! svn_utf__cstring_is_valid(path))
{
return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
_("Path '%s' is not in UTF-8"), path);
}
/* No "." or ".." elements. */
if (svn_path_is_backpath_present(path)
|| svn_path_is_dotpath_present(path))
{
return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
_("Path '%s' contains '.' or '..' element"),
path);
}
/* That's good enough. */
return SVN_NO_ERROR;
}
]]]
Can we just extend it to prohibit all characters with ascii code < 31 ?
--
Ivan Zhakov
