Create a new release key to sign a new apk product¶
The example product here is “rocket”¶
Before the release day: 1. SSH to a Linux (android) signing server 2.
Manually Create a new keystore dedicated to host the new cert. For
future automation, passwords for both keystore and certificate must be
the same I usually use
pwgen 80 for the passphrase, scp down to my
laptop, scp up to the target server, unzip. secure wipe (srm, rm -P,
etc) the files on laptop afterwards. I created a keystore called
“rocket-jar” in /builds/signing/rel-key-signing-server/secrets. The
certificate in there has the alias “rocket”. Just like the release
certificate, I filled these values:
CN=Release Engineering, OU=Release Engineering, O=Mozilla Corporation, L=Mountain View, ST=California, C=US
I also needed to chmod 600 the keystore file and chown so it has the
same owner and group as other signing keystores. 3. Sign the APK 4.
Give the APK back to the Rocket team.
Right after the first APK is signed: I. Store the passwords on the private repo. II. Copy the keystore to the other signing servers. Replication is usually done by archiving the keystore in a zip-encrypted archive. The passphrase is usually 80 chars long III. Create two offline backups of the keys.
For next releases: A. On the signing server, create a new signing format, called something like “rocket-jar” B. Create new instances of the signing server dedicated to that new format. This can be done by either a new process on the same machine (but a different port) or by creating a new machine. C. See whether the Focus team is ready to port a part of their automation to Taskcluster. This would ensure the security of the signing process.
 https://mana.mozilla.org/wiki/display/RelEng/Signing#Signing-Jarsigning(APK)  https://developer.android.com/studio/publish/app-signing.html#sign-apk  https://mana.mozilla.org/wiki/display/RelEng/Signing#Signing-Backups