Issue #1870
closedFailed to sign build due to ClassCastException [patch to fix this needs review]
0%
Description
I try to sign my build with ./vendor/replicant/sign-build i9300
but it fails with some java.lang.ClassCastException
:
0 20:59:24 replicant@debian:~/rsm13% ./vendor/replicant/sign-build i9300 Enter password for /home/replicant/rsm13/vendor/replicant-security/media key> Enter password for /home/replicant/rsm13/vendor/replicant-security/platform key> Enter password for /home/replicant/rsm13/vendor/replicant-security/releasekey key> Enter password for /home/replicant/rsm13/vendor/replicant-security/shared key> rewriting RECOVERY/RAMDISK/default.prop: replace: ro.bootimage.build.fingerprint=replicant_i9300:6.0.1/MOI10E/eng.replicant.20180122.125904:userdebug/test-keys with: ro.bootimage.build.fingerprint=replicant_i9300:6.0.1/MOI10E/eng.replicant.20180122.125904:userdebug/release-keys replace: ro.build.display.id=replicant_i9300-userdebug 6.0.1 MOI10E eng.replicant.20180122.125904 test-keys with: ro.build.display.id=replicant_i9300-userdebug 6.0.1 MOI10E eng.replicant.20180122.125904 replace: ro.build.tags=test-keys with: ro.build.tags=release-keys signing: FusedLocation.apk (/home/replicant/rsm13/vendor/replicant-security/platform) java.lang.ClassCastException: org.bouncycastle.asn1.DLSequence cannot be cast to org.bouncycastle.asn1.ASN1Integer at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.<init>(PrivateKeyInfo.java:79) at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.getInstance(PrivateKeyInfo.java:45) at com.android.signapk.SignApk.readPrivateKey(SignApk.java:250) at com.android.signapk.SignApk.main(SignApk.java:924) ERROR: signapk.jar failed: return code 1 1 20:59:37 replicant@debian:~/rsm13%
The APK seems to be build from ./build/tools/signapk
which is checked-out at tag replicant-6.0-0003
like expected.
The same is true for ./external/bouncycastle
if this matters.
Any ideas?
Updated by Fil Bergamo almost 7 years ago
I remember having a similar issue when trying to sign the build for the first time..
The issue is in the key generation process.
I vaguely remember tweaking the build script somehow to make it compliant to my environment, and then being able to successfully generate keys. Or maybe I had to change something in environment variables..
Unfortunately, I can't remember exactly what I did, I'm sorry.
Maybe you can try by generating your signing keys without a wrapping passphrase, just as a test.
Also, try and take a look inside the script, maybe some hints will come out of it..
But I can tell you, it must be related to something in the signing script that is not perfectly fitting your building environment.
What's the configuration of your building machine?
I had that issue inside a Debian Stretch chroot on a Trisquel7 machine..
Updated by doak complex almost 7 years ago
I vaguely remember tweaking the build script somehow [...]
Thanks to pointing me in this direction. I just thought about code of the Java stuff, I did not take the script itself into account.
I will have a look later and report it here.
Maybe you can try by generating your signing keys without a wrapping passphrase, [...]
I already did this before posting the first time.
What's the configuration of your building machine?
It is a Debian as well: Current testing (buster), running inside Qemu.
Updated by doak complex almost 7 years ago
I have just realised that these two lines
replace: ro.build.display.id=replicant_i9300-userdebug 6.0.1 MOI10E eng.replicant.20180122.125904 test-keys with: ro.build.display.id=replicant_i9300-userdebug 6.0.1 MOI10E eng.replicant.20180122.125904
are suspicious. These are the only lacking
relase-key
...Updated by doak complex almost 7 years ago
Short update:
I was able to strip it down to the call of signapk.jar. I passed the original and some other APKs, no difference. Since the same also occur if some non-existent filename is used, it seems it is not related to the APK but to some prior code.
I did a small Internet research, the error message is known. Let's see if I find the matching problem/solution.
Updated by doak complex almost 7 years ago
Okay, I got it working. I will post the (correct) fix later...
Updated by doak complex almost 7 years ago
Indeed, using passphrases do not work.
Using keys without passphrases failed for me, too, but for a different reason: Some fields are not allowed to be empty, but the script does not provide failure proof defaults.
Sadly I have missed the failure messages on the very first run, since the script itself lackes proper error handling for that case as well.
It works for me now (without passphrases). I improved the script a little (proper defaults, error handling) and sent patches to the mailing list.
Nevertheless, this issue is still valid.
Regards,
doak
Updated by Fil Bergamo almost 7 years ago
Thanks for taking the time to look into this issue..
I haven't had the chance to look into your patch, but thanks anyway for working on it!
Updated by Joonas Kylmälä over 6 years ago
The patches for this issue can be found from https://lists.osuosl.org/pipermail/replicant/Week-of-Mon-20180129/thread.html. Also this issue caused the problem in #1876 which I have now closed so we can keep track of things more easily.
Updated by Kurtis Hanna over 6 years ago
- Subject changed from Failed to sign build due to ClassCastException to Failed to sign build due to ClassCastException [patch to fix this needs review]
Updated by Fil Bergamo over 6 years ago
- Status changed from New to Feedback
- Assignee set to Joonas Kylmälä
Updated by Denis 'GNUtoo' Carikli almost 6 years ago
- Assignee changed from Joonas Kylmälä to Denis 'GNUtoo' Carikli
- Target version changed from Replicant 6.0 to Replicant 6.0 0004
Updated by Denis 'GNUtoo' Carikli almost 6 years ago
- Status changed from Feedback to Resolved
- Assignee changed from Denis 'GNUtoo' Carikli to doak complex
I've merged your patches for that.
Thanks a lot!
Denis.