On 03/27/2013 08:35 AM, Stefan Sperling wrote:
> On Tue, Mar 26, 2013 at 06:42:27PM +0100, Stefan Sperling wrote:
>> On Tue, Mar 26, 2013 at 12:40:56PM -0400, C. Michael Pilato wrote:
>>> 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?
>> I don't really see how supporting such paths in the FS layer makes
>> sense if none of the other layers can deal with them.
>> Are there any other tools built on top of our FS layer that rely on
>> being able to use newlines in filenames?
>> But still, I was planning on making the repos layer enforce restrictions
>> on filenames anyway to avoid having each filesystem deal with it separately.
> I think we'll have to block these paths at the FS layer.
If FSFS is fundamentally unable to support these types of paths, then sure,
let's go ahead and protect against the failure at that level. But please
don't overreach here -- block only the paths that FSFS simply cannot deal
with. There have been other tools built atop the FS layer in the past
(wikis, etc.) and could be in the future -- this is, after all, why we have
distinct FS and repos APIs -- and we shouldn't be artificially limiting what
folks can do with the that API.
As an aside, though, we keep talking about paths with trailing newlines. Is
it only *trailing* newlines that cause the problem here? I would think that
newlines appearing anywhere in the path could be problematic in at least
some of the same places we've discussed on this thread thus far.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-03-27 15:52:41 CET