commit 9dc0208515395911c275fcfe2b716f210c48be12
author Alex Klyubin <klyubin@google.com> Sun Feb 12 14:54:10 2017 -0800
committer Alex Klyubin <klyubin@google.com> Fri Mar 03 14:55:25 2017 -0800
tree 1aabbac4071182908779f17bbc3b33d3040c7b44
parent 66260aaddcdb8c5e4d0782de95c97ab5a5a9cfc4

Make apksigner compatible with jarsigner for non-ASCII passwords

When keytool and jarsigner obtain the keystore/key password via
stdin or console, contrary to the expectation of Java KeyStore API,
they do not appear to encrypt/decrypt the keystore/key using the
Unicode characters comprising the password. Instead, these tools
appear to convert the password to their encoded form (using the
console's character encoding) and then upcast each resulting Java byte
into a Java char. The keystore/key appears to be encrypted using the
resulting array of characters.

This behavior may be a remnant from the early days of Java when there
was no standard way to convert textual input obtained via stdin to
Unicode characters. The behavior is consistent with simply treating
each Java byte read via stdin as a Java char and then passing in the
resulting array of characters into KeyStore API as password.

Unfortunately, when the password is passed in into keytool/jarsigner
via the command-line, or when other tools (including apksigner) use
the Java KeyStore API to create/read keystores/keys, the above
strange behavior does not occur. As a result, there's a mismatch for
non-ASCII passwords.

This commit modifies apksigner to be compatible with both ways of
dealing with keystore/key passwords. For each provided password,
apksigner tries its Unicode character array form, as well as the two
additional forms obtained by encoding the password using the console
character encoding and the JVM's default character encoding.

NOTE: This does not solve the issue of portability of keystores with
non-ASCII passwords between environments with different console
character encodings. For example, a keystore created on Windows 10
with a non-ASCII keystore/key password entered on console with the
(default) IBM437 character encoding is likely to not be decryptable
in an environment which does not use IBM437 character encoding for
the console, such as most modern Linux/OSX machines which normally
use UTF-8 as the character encoding of the console.

https://code.google.com/p/android/issues/detail?id=234089

Test: Use keytool to create two JKS keystores protected using password
      "ab¡äю1" (one where the password is read from the console, the
      other where the password is provided on the command-line). Use
      apksigner to sign an APK using these keystores, providing the
      password via all four methods supported by apksigner. Do this on
      Windows 10 (IBM437 console encoding, windows 1252 file/JVM
      default encoding, OSX (UTF-8), and Linux (UTF-8).
Bug: 35330203
Change-Id: I7a7c215ae87343112f9969ee006791a5c7343754