Re: JDBC driver patch for non-ASCII users

sulfinu@gmail.com wrote:
> On Saturday 08 December 2007, Oliver Jowett wrote:
>
>> Can you explain what this change does, then?
>>
>>>                          String result = UnixCrypt.crypt(salt, password);
>>> -                        byte[] encodedResult =
>>> result.getBytes("US-ASCII"); +                        byte[]
>>> encodedResult = result.getBytes(Encoding.AUTHENTICATION_PHASE_ENCODING);
>> AFAIK UnixCrypt.crypt() should only be returning ASCII anyway, right?
> Wrong, it returns a String, in other words a series of Unicode points, not
> necessarily ASCII characters.

A general String certainly might contain non-ASCII, but all Strings
returned by UnixCrypt.crypt() contain only ASCII. See the implementation
of UnixCrypt.crypt(), and in particular the UnixCrypt.cov_2char array.

So I still do not understand why the change quoted above is necessary.
Can you explain why it is necessary?

>> Same thing re. salt decoding, doesn't the server only ever send ASCII?
> The server never bothers about any encoding during the authentication phase.
> The server simply treats everything as byte arrays and compares what is
> received from the client to the result of its own byte-wise computation,
> based on stored user name and password.

The server only ever sends a subset of ASCII as crypt salt characters
(specifically, the 62 characters a-z A-Z 0-9), so US-ASCII is just fine
for decoding. See postmaster.c, RandomSalt() / RemapChar().

So I still do not understand why a change to the encoding used to decode
crypt salt characters is necessary. Can you explain why it is necessary?

-O