While evaluating the above JCE documentation bug, it was noticed that there are a number of problems with the fallback implementation, which was a direct copy of the code in Password.java.

1) in.read() does a straight conversion from bytes to char, with no character set encoding. ( buf[offset++] = (char) c; ). This could be wrong in 2 byte Unicode circumstances. The java.io.Console.readPassword implementation does the right thing. This could cause keystores created by using Console.readPassword() to be unreadable with apps reading from other inputStreams (say a pipe).

For JCE PKCS5 PBE, this isn't a real problem, but other apps (keystores) use the full 16 bits. This is potentially serious.

2) End of line conversion is not portable. It was pointed out that some pre-OS X Macintosh implementation used "\n" as its line separator instead of "\r" or "\r\n". Our implementation should really be checking for any of these. Again, readConsole does the right thing. However, we don't have the luxury of reading ahead in the InputStream, we need to return the inputstream in a set state. We may want to consider adding some code which reads the "line.separator" system property in a doPrivileged block, and then uses that to flag the EOL. Since this code is in sun.*, and the default system policy in java.policy gives read privilege for "line.separator", this might be an appropriate solution.

3) In case of an Exception, the temporary buffers should be cleared.

    try {
        ...deleted...
    } finally {
        Arrays.fill(buffer, ' ');
    }

All of these issues have has been long-standing issues, but apparently never noticed.

I haven't quite decided how I'm going to fix the 5035358 yet, but I may just use the Console.readPassword() and punt the rest until this is fixed.

Is this something we want to try to fix for mustang?