Null pointer exception when signing keys have password

[shawngustaw]

Release script works fine without passwords on the keys, but otherwise I get the following exception:

$ ./release.sh
Enter password for keys/media key>
Enter password for keys/platform key>
Enter password for keys/releasekey key>
Enter password for keys/shared key>
rewriting RECOVERY/RAMDISK/default.prop:
replace: ro.bootimage.build.fingerprint=Android/aosp_hammerhead/hammerhead:6.0.1/MMB29M/2015.1230.07.51.22:user/test-keys
with: ro.bootimage.build.fingerprint=Android/aosp_hammerhead/hammerhead:6.0.1/MMB29M/2015.1230.07.51.22:user/release-keys
replace: ro.build.display.id=MMB29M.2015.1230.07.51.22 test-keys
with: ro.build.display.id=MMB29M.2015.1230.07.51.22
replace: ro.build.tags=test-keys
with: ro.build.tags=release-keys
replace: ro.build.description=aosp_hammerhead-user 6.0.1 MMB29M 2015.1230.07.51.22 test-keys
with: ro.build.description=aosp_hammerhead-user 6.0.1 MMB29M 2015.1230.07.51.22 release-keys
replace: ro.build.fingerprint=Android/aosp_hammerhead/hammerhead:6.0.1/MMB29M/2015.1230.07.51.22:user/test-keys
with: ro.build.fingerprint=Android/aosp_hammerhead/hammerhead:6.0.1/MMB29M/2015.1230.07.51.22:user/release-keys
rewriting SYSTEM/etc/security/mac_permissions.xml with new keys.
signing: Launcher3.apk (keys/releasekey)
java.lang.NullPointerException
at com.android.signapk.SignApk.decryptPrivateKey(SignApk.java:204)
at com.android.signapk.SignApk.readPrivateKey(SignApk.java:229)
at com.android.signapk.SignApk.main(SignApk.java:913)

ERROR: signapk.jar failed: return code 1

[vmesh]

Same problem

[vmesh]

Same problem

[shawngustaw]

@vmesh can easily get around this by not using passwords on the keys.

[shawngustaw]

@vmesh can easily get around this by not using passwords on the keys.

[vmesh]

@notsrg do you know how to decrypt pkcs#8 private key? I tried:
openssl pkcs8 -in releasekey.pk8 -inform DER -outform DER -out releasekey-unenc.pk8,
but signapk.jar throwing this exception:

java.lang.IllegalArgumentException: unknown object in getInstance: org.bouncycastle.asn1.ASN1Integer
        at org.bouncycastle.asn1.ASN1Sequence.getInstance(ASN1Sequence.java:98)
        at org.bouncycastle.asn1.x509.AlgorithmIdentifier.getInstance(AlgorithmIdentifier.java:47)
        at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.<init>(PrivateKeyInfo.java:85)
        at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.getInstance(PrivateKeyInfo.java:45)
        at com.android.signapk.SignApk.readPrivateKey(SignApk.java:239)
        at com.android.signapk.SignApk.main(SignApk.java:913)

[vmesh]

@notsrg do you know how to decrypt pkcs#8 private key? I tried:
openssl pkcs8 -in releasekey.pk8 -inform DER -outform DER -out releasekey-unenc.pk8,
but signapk.jar throwing this exception:

java.lang.IllegalArgumentException: unknown object in getInstance: org.bouncycastle.asn1.ASN1Integer
        at org.bouncycastle.asn1.ASN1Sequence.getInstance(ASN1Sequence.java:98)
        at org.bouncycastle.asn1.x509.AlgorithmIdentifier.getInstance(AlgorithmIdentifier.java:47)
        at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.<init>(PrivateKeyInfo.java:85)
        at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.getInstance(PrivateKeyInfo.java:45)
        at com.android.signapk.SignApk.readPrivateKey(SignApk.java:239)
        at com.android.signapk.SignApk.main(SignApk.java:913)

[thestinger]

If you generate the keys without setting a password, it will work. These tools are directly from AOSP without any changes at all in CopperheadOS.

[thestinger]

If you generate the keys without setting a password, it will work. These tools are directly from AOSP without any changes at all in CopperheadOS.

[thestinger]

I don't really think it makes sense to support encrypting the keys anyway because there are five of them and they're used multiple times. You would be prompted for the passwords dozens of times. It makes more sense to handle them as a group. You can use whatever mechanism you want to protect the keys but they need to be available for use by the scripts in the build without interaction.

[thestinger]

I don't really think it makes sense to support encrypting the keys anyway because there are five of them and they're used multiple times. You would be prompted for the passwords dozens of times. It makes more sense to handle them as a group. You can use whatever mechanism you want to protect the keys but they need to be available for use by the scripts in the build without interaction.

[thestinger]

I might even have to ask once for each app...

[thestinger]

I might even have to ask once for each app...

[ksuhiyp]

@thestinger so what i am facing this problem too

[ksuhiyp]

@thestinger so what i am facing this problem too

[thestinger]

So then follow the build instructions, which say this:

The keys should not be given passwords due to limitations in the upstream scripts. If you want to secure them at rest, you should take a different approach where they can still be available to the signing scripts as a directory of unencrypted keys. The sample certificate subject can be replaced with your own information or simply left as-is.

Pinging me about it when it's entirely explained here already is just wasting my time...

[thestinger]

So then follow the build instructions, which say this:

The keys should not be given passwords due to limitations in the upstream scripts. If you want to secure them at rest, you should take a different approach where they can still be available to the signing scripts as a directory of unencrypted keys. The sample certificate subject can be replaced with your own information or simply left as-is.

Pinging me about it when it's entirely explained here already is just wasting my time...