You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2005/01/16 17:31:55 UTC

Re: Enforce canonical paths in client-server protocol?

Perhaps I'm not explaining well enough.

What I'm saying is all a consequence of my opinion that we should enforce 
protocols strictly.  If we don't, then in the medium to long term all the 
different possible variations would add up and would all have to be supported. 
  Even if it takes no more code to permit than to reject the variations, the 
definition of the protocol would become a mess and the possibility of extending 
it would be markedly decreased.

When it comes to discussing whether to _increase_ this enforcement, the 
decision is more difficult because we do not want to break existing 
implementations unnecessarily.  So perhaps we should attempt a stage of 
deprecation in which we emit some sort of warnings (how?) when clients are 
behaving badly, and then after a while we should actually refuse to accept the 
bad formatting.

In this case, Peter Lundblad has already changed the "svnserve" protocol 
implementation* to canonicalise all incoming paths, and he didn't see any 
objection so we implicitly approved this approach.  However, if we change this 
from "canonicalise paths" to "ensure paths are canonical", the work of 
discovering where to put the code is not wasted.


As for the implementation quality of "is_canonical", it should be equivalent to 
"canonicalize".  It could just call "canonicalize" and see if the result is any 
different.


So is there any reason not to make "svnserve" strict and make "is_canonical" 
thorough?  How would we have to stage the change to avoid breaking existing 
implementations before they have a chance to be fixed?

- Julian


* r12063, r12084, issue #2119.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Enforce canonical paths in client-server protocol?

Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Sun, 2005-01-16 at 12:31, Julian Foad wrote:
>>What I'm saying is all a consequence of my opinion that we should enforce 
>>protocols strictly.
> 
> As a general rule, I agree.
> 
> But in this specific instance, I don't see any value in going to
> additional effort (and perhaps breaking clients) to strictly enforce
> canonical paths.

Ah, but it's not additional effort.  There are actually three implementation 
options:

+ explicitly reject non-canonical paths;

+ explicitly accept non-canonical paths;

+ don't check; just work if good paths are given and behave indeterminately 
(work/fail/crash) if bad paths are given.

The effort to reject or accept non-canonical paths is equal.  The only 
low-effort approach is to just try to use the paths without checking, but that 
already led to crashes in svnserve so it was deemed unacceptable.

Given that the two acceptable approaches require equal effort, the "perhaps 
breaking clients" is the determining factor, and we haven't determined how much 
of a problem that is.  If it's a big problem then I'll agree it won't be worth it.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Enforce canonical paths in client-server protocol?

Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2005-01-16 at 12:31, Julian Foad wrote:
> What I'm saying is all a consequence of my opinion that we should enforce 
> protocols strictly.

As a general rule, I agree.

But in this specific instance, I don't see any value in going to
additional effort (and perhaps breaking clients) to strictly enforce
canonical paths.  I cannot imagine extending the protocol using
non-canonical path elements (especially since we could not extend the
command-line client syntax in the same way, since non-canonical paths
already have a defined meaning to the command-line client); we simply
have too many other well-defined, good mechanisms for extending our
protocols.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Enforce canonical paths in client-server protocol?

Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:

> As for the implementation quality of "is_canonical", it should be
> equivalent to "canonicalize".  It could just call "canonicalize" and
> see if the result is any different.

When I wrote "is_canonical" it matched "canonicalize", although since
then "canonicalize" has been changed.  As originally written
"is_canonical" is extremely efficient so I called it from lots of
places as a debugging aid.  Making "is_canonical" match the current
"canonicalize" will make it less efficient, I don't know whether it
would be appropriate to call it as frequently.  grep for "Expensive
strlen" to find those places where the current version could not be
called efficiently.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org