Iceraven-browser: Enable proper signing with a release key

[abhijitvalluri]

What is the user problem or growth opportunity you want to see solved?

We need to now enable signing with a proper release key that can be stored as a secret in the github repo.

Now that I have enabled releasing apks from PRs and also release automation, the apks generated via these workflows use a debug key that is generated in the Github actions workflow. This key will likely change from run to run, and more crucially, it will be different from the debug key @interfect uses. Currently, the way things are setup, only interfect can release a app version compatible with previously signed apks. More details about this here.

So, we need to create a release key and store it as a secret in the repo. We could use this github action to do this (https://github.com/r0adkll/sign-android-release) or come up with our own custom solution. Some investigation is necessary to make this work properly.

How do you know that this problem exists today? Why is this important?

We anyway need to use a better and more secure means of signing the apk than a simple debug signing. It will be an important step towards enabling us to release this via F-droid or Google Play Store. It will also make our CI processes more useful, as people can install the signed app without issues.

Who will benefit from it?

Both maintainers + end users will benefit from this.

[abhijitvalluri]

If and when we are doing this, you should upload the secrets to Github repo @interfect as only you have the rights to make such changes to this repo. I have more limited control.

[interfect]

Is there a way to promote the debug key I've been using to be our release key, so we don't make people uninstall and reinstall again? I think it's already in the right format for sign-android-release, and I'm not sure the security benefits against people hacking into my computer are worth re-keying everyone. And if they are we can do it once the build system works.

When we get the F-Droid builds working, they'll all be signed by F-Droid, and that I think would be the properly-secure way to get a build.

[abhijitvalluri]

Unsure. Try this: https://stackoverflow.com/a/42858945
That answer claims that the default values for the debug key are as mentioned. See if you can successfully build via Android studio by pointing to the debug keystore file and using those passwords for the key. If it works then we can use this as a starting point to enable signing via debug keystore. We will somehow need to save the keystore file via a github secret.

[abhijitvalluri]

In the meantime you could create a manual release by building it yourself.

[interfect]

I'm not sure if I can get a successful build out of Android Studio at all. But https://github.com/kaikramer/keystore-explorer takes "android" as the password at least for they key itself.

I've created DEBUG_SIGNING_KEY, DEBUG_ALIAS, DEBUG_KEY_STORE_PASSWORD, and DEBUG_KEY_PASSWORD secrets to try and match what the signer wants in https://github.com/r0adkll/sign-android-release#example-usage. Maybe try those? If they don't work, maybe try an empty DEBUG_KEY_STORE_PASSWORD.

The key itself is 1024 bit RSA which is intentionally a very bad key so people don't use it like this. Once we have signing set up we probably should move to a more legit key.

Android doesn't have a Right Way to migrate signing keys; they just tell you to generate a key that will last for 30 years and hope you will go out of business by then.

I'll see if I can give you secrets access, and build APKs for the tag you made.

[interfect]

OK @abhijitvalluri, you should have secrets access now.

[interfect]

I've also built some APKs, filled in some release notes, and set the 1.1.0 release to released: https://github.com/fork-maintainers/iceraven-browser/releases/tag/iceraven-1.1.0

[abhijitvalluri]

Hmm, there seems to be something wrong with the keys you provided. The signing works and everything, but seems that the certificates do not match!

I compared the certificates (using the following command) for your apk and the one I built via CI:

apksigner verify --verbose --print-certs apkname.apk

and they do not match.

Your apk's output

$ apksigner verify --verbose --print-certs iceraven-browser-arm64-v8a-forkRelease.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1
Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: 9c0d22379f487b70a4f9f8bec0173cf91a1644f08f93385b5b782ce37660ba81
Signer #1 certificate SHA-1 digest: ddd7c3c62dce8c38c391fc67851be4be67fc2b09
Signer #1 certificate MD5 digest: 218659a9d99b5ee7e416164b0d069a26
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: b0a92816b3aa743e9010a3d0a48fc90c50ed12e128d21409bba5fdcf4b80ec8c
Signer #1 public key SHA-1 digest: 38d84a18ae09facca7e8cc9a858b01839b7e70d8
Signer #1 public key MD5 digest: 1a180dacde0610c497a8fbe5fbf2a5df
... (truncated)

CI created apk:

$ apksigner verify --verbose --print-certs app-arm64-v8a-forkRelease-unsigned-signed.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1
Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: 5f85bb9dd89f9f5d14b3bd8e2c72d51e912a4136cf178d6e3d4a57193c0b74e0
Signer #1 certificate SHA-1 digest: 982a891145ed018bebdde3512f43ad0fae7b0f18
Signer #1 certificate MD5 digest: 6c568ffa0bba27e160cc5a2a581669df
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 1024
Signer #1 public key SHA-256 digest: 7abf1355d6baba24d8f1d1f044ff7e6eaa2ef3c80cfab2c26af06b485d9bb921
Signer #1 public key SHA-1 digest: 052d5d4380a5deb1447ac6009dcd1483c8a097de
Signer #1 public key MD5 digest: cd0fe28f706728598c88f14c7c538dc7
... (truncated)

Ignore the Verified using v3 scheme (APK Signature Scheme v3): true in the CI one. I retried locally with v3 signing disabled but the certificates are exactly the same as the CI ones. Which is different from your certificate. Of note is that the CI certificate is a 1024 bit RSA algorithm one. But your apk uses a 2048 bit RSA algorithm. You mentioned earlier that the debug key is generated as a 1024 bit key. So looks like you provided the correct debug key. However your own apks are using a different key.

Once we sort this out, we are in a position to correctly sign the apks via CI.

[abhijitvalluri]

Update:

I tested the above workflow with my own keys. I had a test in a different repository where I stored my debug.keystore and passwords in secrets and let the CI sign the apk. I then manually signed the unsigned apk via the command line (via apksigner command) and they had the same signature and certs. Finally I ran the ./gradlew assembleForkRelease command to see if somehow gradle signs it with a different cert. Nope. This matched with the other two.

So, my conclusion is that the CI workflow works correctly. But you used a different (2048 bit RSA key) for signing the apks that is not your debug key.

Please verify what key you used and add them to the repo via the Github secrets. Then we should be good to go!

[interfect]

OK, I will hunt down the longer key. Maybe the Mozilla build code that obeys local.properties gets its key somewhere else.

September 29, 2020 12:59 PM, "Abhijit Kiran Valluri" <[email protected] (mailto:[email protected]?to=[e-mail])> wrote:
Assigned #169 (https://github.com/fork-maintainers/iceraven-browser/issues/169) to @interfect (https://github.com/interfect).

—

You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub (https://github.com/fork-maintainers/iceraven-browser/issues/169#event-3821446452), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAFXTNSQHWOLLTR3D6MSKI3SII4BLANCNFSM4R3YD7CQ).

[abhijitvalluri]

When I build using the gradle command with that line in my local properties file, it uses my debug key only. So if you are building via that command it should use your debug keys. But if it's using something else that needs to be investigated.

[interfect]

OK, it turns out when I moved where the Android SDK ought to store its ginormous device images I moved where the key lives as well. I found what I think is the right 2048-bit key and installed it as the secret. Maybe it will work now?

[abhijitvalluri]

It works! I verified and I was able to install the CI signed version after installing your version! Closing as this is resolved.