[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fuzzy_escape function in libsvn_subr is not reversible

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-11-09 01:31:35 CET

"Jendro, Carsten (SAZ-DE)" <CJendro@saz.net> writes:
> In a Mail that is explaining the excape sequence there may be a text
> like this
> "Lorem ipsum dolor ?\xxx sit amet, ?\147?\211 consectetur, adipisci
> velit"
> Would be escaped to
> "Lorem ipsum dolor ?\063\xxx sit amet, ?\063\147?\063\211 consectetur,
> adipisci velit"
> And can be simply unescaped 100% by a simple function.
> "Lorem ipsum dolor ?\xxx sit amet, ?\147?\211 consectetur, adipisci
> velit"
> It would work fine.

It only works fine because you *know in advance* that this text was
escaped. But in general, you cannot know that.

Your scheme would make the chances of an unintentional de-escaping
lower, but does not eliminate them completely. There is no way to
know with 100% accuracy whether you're looking at an escaped text, or
at an unescaped text that just happens to be the same as how some
other text would have looked if it had been run through the escaper.

>> In the absence of a well-defined character encoding,
>> reversibility is not achievable. But that is the situation
>> we are in, when we use fuzzy_escape.
>
> The '?' is <= 127 and well-defined in this situation, i dont see the
> problem.

I'm not sure how else to explain it.

Can you show me a text that we can guarantee (by inspection) could
*only* be produced by putting some other text through fuzzy_escape()?
I claim no -- there is no such text, therefore there is no
modification we can make to fuzzy_escape() to generate such texts.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 9 01:31:45 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.