Re: utf-8 encoding scheme

["H. Peter Anvin" <hpa@xxxxxxxxx>]

Followup to:  <Pine.BSI.3.91.1000728003849.26050D-100000@xxxxxxxxxxxxx>
By author:    Henry Spencer <henry@xxxxxxxxxxxxx>
In newsgroup: linux.utf8

> Um, no, I think you've missed my point.  The user of a decoder is *not*
> going to get bitten by these security holes, because he's
> *decoding*.

... and thus losing any verification done by any other layer of
software.

> The act of decoding transforms the input into a form where these
> holes do not exist.  The potential for security holes comes when you
> attempt to use the raw input, *without* decoding it.  It is the
> *non-decoding* users who are vulnerable.

Great.  Now you have a datastream with may contain, say, embedded '/'
in filenames, or null characters.  If you then convert them back to
UTF-8 you now have a string referring to a potentially completely
different file than you started with.  If this isn't a security hole,
I don't know what is.

> This being so, decoding users -- who are not vulnerable -- may balk at
> having their programs misbehave on inputs which do not threaten them anyway.

This is complete nonsense.  See above.

> > Implicit aliases are very dangerous.
> 
> I agree, but the problem is to protect the non-decoding users, and doing
> substitutions in decoders may not be the best way to do that. 
-- 
<hpa@xxxxxxxxxxxxx> at work, <hpa@xxxxxxxxx> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/