Re: Unicode versioning in glib
- From: Simon Josefsson <jas extundo com>
- To: "butterbrain" <bbrain adelphia net>
- Cc: <gtk-i18n-list gnome org>
- Subject: Re: Unicode versioning in glib
- Date: Sun, 06 Oct 2002 01:49:36 +0200
"butterbrain" <bbrain adelphia net> writes:
>> I'm not sure what your point is, but if you mean that this is enough
>> for a protocol that compares normalized strings (such as passwords)
>> for equality the point is not valid. The protocols I'm implementing
>> currently requires that all protocol implementations must use NFKC
>> from Unicode 3.2.
>
> all normalisation of passwords should be done on the trusted machine
> on which the password is typed.
This is the case. Usually passwords are entered into the server
machine and given to the user and entered into client machines.
Normalization must happen in both the server and in the client.
> the storage of the password should be a hash of the string that was
> input.
This prevents use of some authentication methods, such as CRAM-MD5,
which must have access to the raw unhashed password during each
authentication.
> the verification of the password never requires a specific
> encoding.
Right, after normalization it is treated as a binary string in both
client and server.
> it's acceptable to input your password with something other than a
> keyboard, or with keys on a keyboard that don't map to characters or
> unicode values of any kind!
What kind of keyboard is this? Text passwords that can't be
represented in Unicode seems like a rather marginal thing. And
non-textual passwords are not within my current scope.
> the protocol which you are implementing is broken.
How so? I'm sure that e.g. the SASL working group would like to hear
this elaborated.
> in any event you are probably interested in this file as well:
> http://www.unicode.org/Public/UNIDATA/NormalizationCorrections.txt
I'm aware of it; and Unicode Inc. has promised to not "correct"
normalizations in the future.
None of this answers my original question though, but if it should be
infered that GLIB will not support multiple Unicode versions because
what I want to use it for is fundamentally broken, then I'll simply
continue to use the code I copied from GLIB and updated for Unicode
3.2 and withdraw my feature request.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]