On 03/27/2013 12:12 PM, Julian Foad wrote: > My thoughts: > > The key issue is we need to define 'valid path' for the FS layer, and > follow through with documenting it, implementing run-time checks, and > testing it.
The definition of a 'valid path' for the FS layer has existed since long before 1.0: UTF8-encoded, no NUL characters, '/' as component separator, no '.' or '..' components, and empty components treated as if they weren't there at all. And yes, it's documented in the same place it has been for(effectively)ever -- svn_fs.h. I don't spot any run-time checks for the disallowed '.' and '..' components. And I'm pretty sure we don't explicitly test our path support at the requisite level (libsvn_fs C tests). Those things should be remedied. > Something like the proposal above, to reject LF only at the FS (or FSFS) > layer, and all control characters in libsvn_repos, sounds good to me. We > should write unit tests to ensure that the FS layer works properly with > all other control characters. Agreed. This is, however, not a 1.8.0 blocker, IMO By its very design in this areas, FSFS in Subversion 1.1 already introduced a regression-turned-incompatibility versus Subversion 1.0. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
