Fixed
Status Update
No update yet.
Comments
kl...@google.com
Fix landed and should appear in apksigner version 0.5.
kl...@google.com
This is fixed in apksigner version 0.5 which has been released in Android SDK Build Tools 25.0.3.
cb...@google.com
ap...@google.com
Project: platform/tools/apksig
Branch: master
commit 76d14b580f08fc3f84aaf3ebabdb7197bfbfcb2b
Author: Alex Klyubin <klyubin@google.com>
Date: Tue Jul 25 13:38:52 2017
Add --pass-encoding parameter to apksigner
When keytool creates a KeyStore or key which is protected with a
password containing non-ASCII characters, keytool may encode the
password using the console's encoding or the JVM default encoding
instead of using the password verbatim, in its Unicode form. In
apksigner 0.5 support was added to handle this issue by having
apksigner try several variants of the password: verbatim/Unicode,
encoded using console encoding, and encoded using JVM default
encoding. Unfortunatly, there is no public API to obtain the
console's encoding. apksigner 0.5 cheated by accessing
Console.encoding field via Reflection API. This is no longer
advisable in Java 9 because access to such private API is brittle
and now leads to JVM warnings spewing on the standard output.
To make apksigner compatible with Java 9, apksigner's behavior is
being changed by this commit. apksigner no longer attempts to detect
console encoding on Java 9. Those users which use non-ASCII password
keystores/keys created by keytool in environments where console
encoding is not the same as the JVM default encoding, such as English
Windows where console encoding is ibm437 and JVM default encoding is
windows-1252, will need to pass in the new --pass-encoding <encoding>
parameter (e.g., --pass-encoding ibm437) to tell apksigner to try
a password variant encoded using that encoding, in addition to trying
the Unicode and JVM default encoding variants of the password.
The --pass-encoding parameter enables apksigner to work with non-ASCII
password keystores/keys created on different OSes and/or in other
locales than the one in which apksigner is running. For example, this
enables apksigner on OSX and Linux (where the console and JVM default
encoding is UTF-8) to use a non-ASCII password keystore created by
keytool on English Windows, where the resulting password is encoded
using the ibm437 or windows-1252 encoding.
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, using Java 8 and
Java 9 (revision 181), 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: 37135737
Bug: 37137869
Change-Id: Ia6fb0706e4bb3f0fd968373d113d457e8c6260c8
M src/apksigner/java/com/android/apksigner/ApkSignerTool.java
M src/apksigner/java/com/android/apksigner/PasswordRetriever.java
M src/apksigner/java/com/android/apksigner/help_sign.txt
https://android-review.googlesource.com/454516
https://goto.google.com/android-sha1/76d14b580f08fc3f84aaf3ebabdb7197bfbfcb2b
Branch: master
commit 76d14b580f08fc3f84aaf3ebabdb7197bfbfcb2b
Author: Alex Klyubin <klyubin@google.com>
Date: Tue Jul 25 13:38:52 2017
Add --pass-encoding parameter to apksigner
When keytool creates a KeyStore or key which is protected with a
password containing non-ASCII characters, keytool may encode the
password using the console's encoding or the JVM default encoding
instead of using the password verbatim, in its Unicode form. In
apksigner 0.5 support was added to handle this issue by having
apksigner try several variants of the password: verbatim/Unicode,
encoded using console encoding, and encoded using JVM default
encoding. Unfortunatly, there is no public API to obtain the
console's encoding. apksigner 0.5 cheated by accessing
Console.encoding field via Reflection API. This is no longer
advisable in Java 9 because access to such private API is brittle
and now leads to JVM warnings spewing on the standard output.
To make apksigner compatible with Java 9, apksigner's behavior is
being changed by this commit. apksigner no longer attempts to detect
console encoding on Java 9. Those users which use non-ASCII password
keystores/keys created by keytool in environments where console
encoding is not the same as the JVM default encoding, such as English
Windows where console encoding is ibm437 and JVM default encoding is
windows-1252, will need to pass in the new --pass-encoding <encoding>
parameter (e.g., --pass-encoding ibm437) to tell apksigner to try
a password variant encoded using that encoding, in addition to trying
the Unicode and JVM default encoding variants of the password.
The --pass-encoding parameter enables apksigner to work with non-ASCII
password keystores/keys created on different OSes and/or in other
locales than the one in which apksigner is running. For example, this
enables apksigner on OSX and Linux (where the console and JVM default
encoding is UTF-8) to use a non-ASCII password keystore created by
keytool on English Windows, where the resulting password is encoded
using the ibm437 or windows-1252 encoding.
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, using Java 8 and
Java 9 (revision 181), 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: 37135737
Bug: 37137869
Change-Id: Ia6fb0706e4bb3f0fd968373d113d457e8c6260c8
M src/apksigner/java/com/android/apksigner/ApkSignerTool.java
M src/apksigner/java/com/android/apksigner/PasswordRetriever.java
M src/apksigner/java/com/android/apksigner/help_sign.txt
ap...@google.com
Project: platform/tools/apksig
Branch: master
commit 41ca1d3f507de47becdf57f0713f5deab93c645e
Author: Alex Klyubin <klyubin@google.com>
Date: Wed Aug 09 09:30:22 2017
Bump apksigner version to 0.8
Changes since 0.7:
* Java 9 support: apksig and apksigner compile and run on Java 9
* User-friendlier error when unsupported digest or signature
algorithm in JAR signature
* New --pass-encoding parameter to deal with KeyStores and keys
encrypted using non-ASCII passwords. Existing setups with apksigner
and non-ASCII password KeyStores/keys may need to start using this
parameter after the switch to Java 9. See 'apksigner sign' help page
for more information.
* RDNs in PKCS #7 SignerIdentifier are no longer re-encoded (e.g.,
from Utf8String to PrintableString). Instead, the referenced X.509
certificate's Issuer DN is used verbatim.
Test: apksigner version
Bug: 37135737
Bug: 37137869
Bug: 63525618
Change-Id: I4a4f9639a3c1c08b8c89b076e4bed5be6680b79a
M src/apksigner/java/com/android/apksigner/ApkSignerTool.java
https://android-review.googlesource.com/455217
https://goto.google.com/android-sha1/41ca1d3f507de47becdf57f0713f5deab93c645e
Branch: master
commit 41ca1d3f507de47becdf57f0713f5deab93c645e
Author: Alex Klyubin <klyubin@google.com>
Date: Wed Aug 09 09:30:22 2017
Bump apksigner version to 0.8
Changes since 0.7:
* Java 9 support: apksig and apksigner compile and run on Java 9
* User-friendlier error when unsupported digest or signature
algorithm in JAR signature
* New --pass-encoding parameter to deal with KeyStores and keys
encrypted using non-ASCII passwords. Existing setups with apksigner
and non-ASCII password KeyStores/keys may need to start using this
parameter after the switch to Java 9. See 'apksigner sign' help page
for more information.
* RDNs in PKCS #7 SignerIdentifier are no longer re-encoded (e.g.,
from Utf8String to PrintableString). Instead, the referenced X.509
certificate's Issuer DN is used verbatim.
Test: apksigner version
Bug: 37135737
Bug: 37137869
Bug: 63525618
Change-Id: I4a4f9639a3c1c08b8c89b076e4bed5be6680b79a
M src/apksigner/java/com/android/apksigner/ApkSignerTool.java
Description
For example, on Windows 10 with English US as the UI language, the console/stdin uses IMB437 as the character encoding. Assuming the six character password "ab¡äю1" (0x0061 0x0062 0x00a1 0x00e4 0x044e 0x0031 in big-endian hexadecimal representation):
$ keytool -genkey -v -keystore native.jks -keyalg RSA -keysize 2048 -validity 10000 -alias test
generates a keystore and key protected with 0x0061 0x0062 0x00ad 0x0084 0x003f 0x0031
whereas
$ keytool -genkey -v -keystore native.jks -keyalg RSA -keysize 2048 -validity 10000 -alias test -storepass ab¡äю1
generates a keystore and key protected with 0x0061 0x0062 0x00a1 0x00e4 0x003f 0x0031
The same command-lines on modern Linux/OSX which these days use UTF-8 by default for console produces keystores encrypted using:
0x0061 0x0062 0x00c2 0x00a1 0x00c3 0x00a4 0x00d1 0x008e 0x0031
and
0x0061 0x0062 0x00a1 0x00e4 0x044e 0x0031
respectively.
This weird behavior might be a remnant of the early days of Java where there was no Console (which automatically provides Unicode characters as input and thus has a concept of character encoding of standard input) nor a standard concept of character encoding for standard input. jarsigner appears to follow the same behavior, potentially to remain compatible with old keystores from those days and with current versions of keytool.
To complicate matters, keytool is not the only means of creating keystores which are used for signing APKs. For example, Android Studio offers this functionality as well. Thus, apksigner needs to try both the password represented as Unicode characters as well as the password represented as the form encoded according to the console's character encoding.