Fixed
Status Update
Comments
kl...@google.com <kl...@google.com> #2
Thank you very much for reporting this issue, Jack. Looks like the issue is caused by somewhat unnecessary and contrived logic in apksigner.bat, which is special-casing -J* parameters. Unfortunately, this logic doesn't handle whitespace containing parameters, even those which aren't -J*.
I've uploaded a tentative fixhttps://android-review.googlesource.com/#/c/394238/ for review. The patched apksigner.bat is attached. This fixes the issue on my Windows 10 box.
Jack, please test the fix in your environment and let us know whether it works for you too.
I've uploaded a tentative fix
Jack, please test the fix in your environment and let us know whether it works for you too.
kl...@google.com <kl...@google.com> #3
Confirmed, that fix works. Thank you for the quick turn-around on this.
kl...@google.com <kl...@google.com> #4
Project: platform/tools/apksig
Branch: master
commit b293b2087837853e32a1cff008d58644dbbd4cc2
Author: Alex Klyubin <klyubin@google.com>
Date: Wed May 10 16:53:25 2017
Handle whitespace when removing -J* parameters in .bat
apksigner.bat contains special logic for -J* parameters. This logic
was not designed to handle parameters containing whitespace. This
commit fixes the issue. It is unclear whether this -J* logic is even
needed. So, if it keeps breaking stuff, we should probably simply
remove it.
Test: apksigner sign --ks "nonexistent.jks" --ks-pass pass:123123 --ks-key-alias "bug apksigner test" nonexistent.apk
Fails with FileNotFoundException instead of "a was unexpected at this time"
Bug: 38132450
Change-Id: Ice3294e9993b075533c77d94eb870cfd35a65bbc
M etc/apksigner.bat
https://android-review.googlesource.com/394238
https://goto.google.com/android-sha1/b293b2087837853e32a1cff008d58644dbbd4cc2
Branch: master
commit b293b2087837853e32a1cff008d58644dbbd4cc2
Author: Alex Klyubin <klyubin@google.com>
Date: Wed May 10 16:53:25 2017
Handle whitespace when removing -J* parameters in .bat
apksigner.bat contains special logic for -J* parameters. This logic
was not designed to handle parameters containing whitespace. This
commit fixes the issue. It is unclear whether this -J* logic is even
needed. So, if it keeps breaking stuff, we should probably simply
remove it.
Test: apksigner sign --ks "nonexistent.jks" --ks-pass pass:123123 --ks-key-alias "bug apksigner test" nonexistent.apk
Fails with FileNotFoundException instead of "a was unexpected at this time"
Bug: 38132450
Change-Id: Ice3294e9993b075533c77d94eb870cfd35a65bbc
M etc/apksigner.bat
cb...@google.com <cb...@google.com>
as...@gmail.com <as...@gmail.com> #5
Project: platform/tools/apksig
Branch: master
commit 0f88b97634034673f062a8ac6c3dab7d3d9befe3
Author: Alex Klyubin <klyubin@google.com>
Date: Thu Jun 22 09:43:22 2017
Bump apksigner version to 0.7
Changes since 0.6:
* Fixed a bug in whitespace handling in command-line parameters in
apksigner.bat.https://issuetracker.google.com/issues/38132450
* Fixed a bug in JAR signature verification when multiple digests
are present for the same named entry in MANIFEST.MF.
https://issuetracker.google.com/issues/38497270
* Honor android:targetSandboxVersion (introduced in Android O) when
verifying APKs. When android:targetSandboxVersion is set to 2 or
higher, the APK is required to be signed with APK Signature Scheme
v2.
* When signing, reject APKs with CR, LF or NUL in ZIP entry names.
Such names are not permitted by the JAR siging spec and are also
rejected by Android Package Manager.
Test: apksigner version
Bug: 38132450
Bug: 38497270
Bug: 36426653
Bug: 62211230
Change-Id: Ifa120b0e43b458c99c3da6fde1136e0cbb92caee
M src/apksigner/java/com/android/apksigner/ApkSignerTool.java
https://android-review.googlesource.com/420784
https://goto.google.com/android-sha1/0f88b97634034673f062a8ac6c3dab7d3d9befe3
Branch: master
commit 0f88b97634034673f062a8ac6c3dab7d3d9befe3
Author: Alex Klyubin <klyubin@google.com>
Date: Thu Jun 22 09:43:22 2017
Bump apksigner version to 0.7
Changes since 0.6:
* Fixed a bug in whitespace handling in command-line parameters in
apksigner.bat.
* Fixed a bug in JAR signature verification when multiple digests
are present for the same named entry in MANIFEST.MF.
* Honor android:targetSandboxVersion (introduced in Android O) when
verifying APKs. When android:targetSandboxVersion is set to 2 or
higher, the APK is required to be signed with APK Signature Scheme
v2.
* When signing, reject APKs with CR, LF or NUL in ZIP entry names.
Such names are not permitted by the JAR siging spec and are also
rejected by Android Package Manager.
Test: apksigner version
Bug: 38132450
Bug: 38497270
Bug: 36426653
Bug: 62211230
Change-Id: Ifa120b0e43b458c99c3da6fde1136e0cbb92caee
M src/apksigner/java/com/android/apksigner/ApkSignerTool.java
ap...@google.com <ap...@google.com> #6
The fix has been released in apksigner 0.7, released as part of Android SDK Build Tools 26.0.1.
ap...@google.com <ap...@google.com> #7
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.