562843 - Android release signing

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[Aki Sasaki (not active)]

After we figure out how to sign Android nightlies, we need a solution for release signing.

Comment 1

[Aki Sasaki (not active)]

Hm,

http://developer.android.com/guide/publishing/app-signing.html#overview :

"The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates."

http://www.devx.com/wireless/Article/39972/1954 :

"All Android applications must be signed before they are allowed to be deployed onto a device (or emulator). Unlike other mobile platforms, you need not purchase digital certificates from a certificate authority (CA). Instead, you can generate your own personal certificate and use it to sign your Android applications."

From further investigation, it seems like they're actively *discouraging* you from purchasing a CA signed cert.

Comment 2

[Aki Sasaki (not active)]

Bear: do you think this would work?  I'm not seeing anything on verisign.com that specifies Android other than a VIP Access mobile client.

http://www.verisign.com/code-signing/content-signing-certificates/sun-java/index.html?sl=productdetails

Comment 3

[Aki Sasaki (not active)]

Contacted Verisign via web form; waiting for a response.

Comment 4

[Aki Sasaki (not active)]

Spoke to Verisign otp today; got verbal recommendations that make sense.
They will send me some emails tonight; I will follow up tomorrow.

We're tossing the idea of somehow combining our Authenticode and Java signing certs, which would be theoretically possible but not recommended and not Verisign-supported.  We will purchase a Java signing cert specifically for Android releases.

Comment 5

[Aki Sasaki (not active)]

Trying to get an expire/renew scenario tested, having issues with that.
X.509 validity seems to be what we're looking at.

keytool -keyclone doesn't seem to support changing the validity period. The docs I've found for "renewing" an X.509 cert seem to all involve revoking and re-creating the cert.

http://en.wikipedia.org/wiki/X.509#Sample_X.509_certificates seems to suggest that one could decode the cert, edit the text to change the Validity Not Before: and Not After: lines, and re-encode (self-sign? Verisign-sign?) but this seems like a very fiddly process and I'd want to see it successfully install over a build signed with the previous, expired cert.

Still digging.
Sent an email to Verisign to see if they want to help out; if we're not able to get an expire/renew scenario tested (and successfully install a new build signed with the renewed key on top of an old build signed with the old key) then something like a 25-year self-signed cert would seem safer.

Comment 6

[Mike Taylor [:bear]]

I don't think i've ever successfully done the "fiddly" method by editing the Before/Not After bits and re-encoding.  The method used in the past in my experience has been long duration certs and when you do come up on an expiration you sign the new cert with the same key as the expired cert and list it in the trust chain.  But that also never really was for anything as high profile as Mozilla's products, so yea, let's see what Verisign recommends.

25 years always seems far away until it suddenly isn't ;)

Comment 7

[Aki Sasaki (not active)]

Aha.

# Generate new 2048 bit RSA key, and a Certificate Signing Request for the CA
openssl req -new -newkey rsa:2048 -keyout server.key -out server.csr

# Examine the csr
openssl req -in server.csr -noout -text

# Create a self-signed x.509 cert that expires in 30 days from CSR
openssl x509 -req -days 30 -in server.csr -signkey server.key -out server.cert

# Examine cert
openssl x509 -in server.cert -noout -text

# Create a second self-signed x.509 cert that expires in 365 days from same CSR
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server2.cert

# Examine 2nd cert
openssl x509 -in server2.cert -noout -text

Next: import this into a keystore.  If this isn't easily doable, I can generate the CSR from |keytool -certreq| instead.

After that: sign 2 Android builds with 2 different certs signed with the same private key. Test installing one on top of the other without uninstalling.

Comment 8

[Aki Sasaki (not active)]

keytool -importcert -keystore test2.keystore -file openssl/server.cert -alias cert1

worked.
Not sure if that means I can sign something with this keystore or not; testing that now.

Comment 9

[Aki Sasaki (not active)]

When I try to sign using this keystore, I get:

jarsigner: Certificate chain not found for: cert1.  cert1 must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.

I'm guessing this is because I didn't import the key; found some instructions on how to do that here: http://www.agentbob.info/agentbob/79-AB.html .

I think I'm going to try generating the key and csr in keytool itself first.

Comment 10

[Aki Sasaki (not active)]

How to export the private key from the keystore:
http://conshell.net/wiki/index.php/Keytool_to_OpenSSL_Conversion_tips
Looks like both approaches (importing a key into keystore, exporting a key from keystore) require java.

Comment 11

[Aki Sasaki (not active)]

When running hte javac command in http://conshell.net/wiki/index.php/Keytool_to_OpenSSL_Conversion_tips , I had to remove the line in Base64Coder.java that says "package biz.source_code.base64Coder;" to get it to compile.

Then I ran into the all-on-one-line issue (
 $ openssl pkcs8 -inform PEM -nocrypt -in foo-pkcs8.key -out foo.key
 Error decrypting key
 26898:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:759:
)
which I fixed by opening the pkcs8.key in a text editor and adding newlines so no line was >64chars.

I then generated a csr via keytool -certreq, created a cert from the private key, imported that cert via keytool -importcert, and I'm getting the exact same error as comment 9.

I'm guessing I'm importing wrong.

Comment 12

[Aki Sasaki (not active)]

Aha: http://forums.sun.com/thread.jspa?threadID=5281615 tells me I need to import the cert with the same alias.

You can tell when you keytool -keystore KEYSTORENAME -list, a cert imported with a new alias will show up as a "trustedCertEntry"; a cert created via keytool (or imported over a cert created via keytool) will show up as "PrivateKeyEntry".

Signing with that cert worked. [!]

If I generate the private key outside of keytool, none of the certs show up as "PrivateKeyEntry" -- guessing I need to do something else to import the key, or maybe that's not supported.  Either way, this is progress.

Comment 13

[Aki Sasaki (not active)]

I signed two apks, one with a cert that was going to expire in 30 days, the second with a cert (signed with the same key) that was going to expire in 60 days.

Bear attempted to install the second on top of the first, (adb install -r), and got "INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES" which is here:

http://www.google.com/codesearch/p?hl=en#5oTG8Wvrixk/trunk/android-x86/frameworks/base/core/java/android/content/pm/PackageParser.java&q=INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES&sa=N&cd=2&ct=rc&l=406

After examining that chunk of code, and disclaiming that I'm not a java programmer, it looks very much like there is no support for cert renewal.

Comment 14

[Aki Sasaki (not active)]

Filed http://code.google.com/p/android/issues/detail?id=10020

Comment 15

[Aki Sasaki (not active)]

Hm, http://developer.android.com/guide/publishing/app-signing.html#cert now says (or I've just now noticed):

"[Your cert must have] a validity period that exceeds the expected lifespan of the application or application suite. A validity period of more than 25 years is recommended.

If you plan to publish your application(s) on Android Market, note that a validity period ending after 22 October 2033 is a requirement. You can not upload an application if it is signed with a key whose validity expires before that date."

I had read the first paragraph, but the second is new to me.
However, we've already come to the conclusion that a long-lived (>23 years, apparently) self-signed cert is the way we need to go.

Comment 16

[Aki Sasaki (not active)]

Attachment: allow for interactive mozpass mode

This is to avoid the passphrases from living in cleartext on disk or on screen.

Comment 17

[Aki Sasaki (not active)]

Despite my misgivings, the win32 signing box may be our best option.

SDK here: http://developer.android.com/sdk/index.html
JDK here: http://www.oracle.com/technetwork/java/javase/downloads/index.html

Putting the jdk bin + the sdk tools directories in the user PATH works... ran some tests on my win32 Fusion vm.

Comment 18

[Aki Sasaki (not active)]

This works for me in a cygwin bash script with a patched mozpass.py... it asks for the passphrases interactively.

export PATH=$PATH:/cygdrive/c/Program\ Files/Java/jdk1.6.0_21/bin:/cygdrive/c/an
droid/android-sdk-windows/tools
export JAVA_HOME=/cygdrive/c/Program\ Files/Java/jdk1.6.0_21

cp gecko-unsigned-unaligned.apk gecko-unaligned.apk
#python tools/release/signing/mozpass.py -i --keystore mykeystore.keystore --ali
as myalias --apk gecko-unaligned.apk
python mozpass.py -i --keystore mykeystore.keystore --alias myalias --apk gecko-
unaligned.apk
zipalign -f -v 4 gecko-unaligned.apk fennec.apk

Comment 19

[Mike Taylor [:bear]]

Comment on attachment 468114 [details] [diff] [review]
allow for interactive mozpass mode

I have two questions tho - 1) you got rid of the doctest-if-no-args passed, could you not have kept it but added a --test-code option?

2) now that interactive mode introduces the need to parse the command line, we could make parseConfig() return a dictionary to pass to the code that is used to populate the OptionParser's default values.  This would remove the need for Template

Comment 20

[Aki Sasaki (not active)]

(In reply to comment #19)
> I have two questions tho - 1) you got rid of the doctest-if-no-args passed,
> could you not have kept it but added a --test-code option?

I thought about that.
a) we have a --test-only mode that spits out the command line as parsed
b) we have dozens and dozens of working config files to use as samples if needed

Do you still need this?

That does remind me -- I should probably comment out the --test-only option for production runtime.

> 2) now that interactive mode introduces the need to parse the command line, we
> could make parseConfig() return a dictionary to pass to the code that is used
> to populate the OptionParser's default values.  This would remove the need for
> Template

Sure.
I wanted to get the minimal amount of changes in to get interactive mode in time for today, without affecting nightly signing logic at all.

Comment 21

[Mike Taylor [:bear]]

(In reply to comment #20)
> (In reply to comment #19)
> > I have two questions tho - 1) you got rid of the doctest-if-no-args passed,
> > could you not have kept it but added a --test-code option?
> 
> I thought about that.
> a) we have a --test-only mode that spits out the command line as parsed
> b) we have dozens and dozens of working config files to use as samples if
> needed
> 
> Do you still need this?

the doctest was testing the code's internal interfaces - not the functional testing from the outside.  but if the --test-only is excercing the same code-paths then it's the same behaviour. just did not want to lose test coverage even for such a simple tool.
> 
> That does remind me -- I should probably comment out the --test-only option for
> production runtime.
> 
> > 2) now that interactive mode introduces the need to parse the command line, we
> > could make parseConfig() return a dictionary to pass to the code that is used
> > to populate the OptionParser's default values.  This would remove the need for
> > Template
> 
> Sure.
> I wanted to get the minimal amount of changes in to get interactive mode in
> time for today, without affecting nightly signing logic at all.

yea, that's why I r+'d it with comment

Comment 22

[Aki Sasaki (not active)]

Comment on attachment 468114 [details] [diff] [review]
allow for interactive mozpass mode

http://hg.mozilla.org/build/tools/rev/0c0f5f87afa0

I checked this in with the echo bit commented out; got a little paranoid that someone could use that in a not-good way.

Comment 23

[Aki Sasaki (not active)]

This appears to be resolved.
Documentation is up for the build team. It can definitely become more uniform with Firefox desktop signing, but we have Android release signing.