ci(workflow): add PGP key and checksum signing

[xmready]

No description provided.

[Inhishonor]

Thanks, looks good to me!

[xmready]

Should I push the signing key changes as a separate PR, or push it to this one? Given the title of the PR might be good to separate them..

[xmready]

A strategy for generating the signing key and importing it into GitHub secrets still needs to be decided upon

[Inhishonor]

@xmready Would you mind rebasing your changes on top of the latest version of the workflow?

[xmready]

@Inhishonor I merged the changes from master. I prefer merge instead of rebase. It's good practice for shared projects because rebasing can rewrite commit hashes and things get ugly if working in the same branch.

I also pushed a fix commit to make sure the signature file is in the outputs. I almost did a good job keeping those changes separate from the merge commit. Next time I'll do it perfectly haha

[beackers]

@xmready A method strategy for generating the signing key and importing it into Github secrets still needs to be decided on

Suggestion for signing. I've used this method a few times and it seems to work well.

In short: convert a keystore to a base-64 file, put the contents in a Github repo secret, then use that secret to reconstruct the keystore in the runs.

1. JDK versions come with keytool; use that to generate the keystore. I do this in a Codespace. (Replace stuff with <>.)

keytool -genkey -alias <a random alias> -keystore \<the keystore filename>.jks \\
-keyalg RSA -keysize 2048 \\
-validity 360000

Remember the alias and keystore password. Kinda important.
2. Convert to a base64 file:

base64 \<the keystore filename>.jks > \<some other filename>.jks.b64

3. Paste the contents of the b64:

cat \<the base64 file>.jks.b64

Copy that.
4. Create a new GitHub repository secret, call it something like "RELEASE_KEYSTORE_B64" or something, and paste the b64 contents as the secret.
5. In your CI workflow, add a step to decode the keystore and save it:

      - name: Reconstruct keystore
        env:
          RELEASE_KEYSTORE_B64: ${{ secrets.RELEASE_KEYSTORE_B64 }}
        run: |
          echo "$RELEASE_KEYSTORE_B64" | base64 --decode > regenwall.keystore

      - name: Build release APK
        run: ./gradlew assembleRelease
        env:
          RELEASE_KEYSTORE_PASSWORD: ${{ secrets.RELEASE_KEYSTORE_PASSWORD }}
          RELEASE_KEY_ALIAS: ${{ secrets.RELEASE_KEY_ALIAS }}
          RELEASE_KEY_PASSWORD: ${{ secrets.RELEASE_KEY_PASSWORD }}

(taken from my app ReGenWall's release workflow)
6. If you feel like you need to clean up (i.e. you'll use the Codespace for actually commiting stuff later), remove the keystore and b64 file.

If this question still needs an answer, hope that helps.

Edit: change quote

[Inhishonor]

@xmready Can you remove the PGP change, and just add the checksum signing? I would like to get that part merged asap, but the rest needs some more careful consideration.

[xmready]

@xmready Can you remove the PGP change, and just add the checksum signing? I would like to get that part merged asap, but the rest needs some more careful consideration.

@Inhishonor I don't understand rushing the checksum changes without the PGP part. Checksums are meaningless to anyone serious about security if they lack cryptographic verification. If we need to make considerations, let's go ahead and do it. This is an area that I have experience in. I posted a plan in the development matrix room. Generating a signing key in a codespace is not secure. I'll repost my thoughts here for transparency:

For the PGP signing key, I'm thinking we generate it offline with a revocation certificate. The main key would not expire, but we would generate a subkey with an expiration date. The subkey would be rotated out as need after expiration. This way only subkey is trusted to GitHub secrets, and the parent key is generated and stored only offline. The public key would be published to a keyserver so people can fetch and update the key as needed. We could also decide to have more than one signing key belonging to more than one maintainer both signing the checksums, depends on how robust we want to make this. This is common practice for high stakes projects, maybe only one key is needed in this situation.

[Inhishonor]

Thanks @xmready. Sorry about missing your post in Matrix. I was unsure how to handle it, as I have little experience here and then I forgot about it. Let's figure this out then and get it merged.