Use one signing key per PR

[opusforlife2]

Describe the feature you want

We need to figure out a way for Github Actions to use the same signing key for all builds in a single PR.

Is your feature request related to a problem? Please describe it

Currently, Github Actions builds artifacts that are signed with a different key each time the job is run. This causes a problem: you cannot install a new APK on top of an older APK from the same PR. This forces you to back up the database, uninstall the older APK, install the new one, and then restore the backup. Needless to say, this is quite annoying for testers of multiple PRs.

[TheAssassin]

This causes a problem: you cannot install a new APK on top of an older APK from the same PR.

That problem can be solved otherwise, too. You could add a random ID to the APK identifiers, for instance. That would be much easier than fiddling with signing keys.

But I think there are some benefits in taking a look at signing keys as well. Let's analyze @opusforlife2's points and do some good old requirements engineering, adding some important additional requirements.

Functional requirements:

• have the same key sign all APKs used to test a pull request

Nonfunctional requirements:

• make it easy to setup for PR authors (I don't think it can or should be automated, though)
• use different keys for different PRs to limit the amount of people who could possibly access that key
• no centralized builds in our project so that keys cannot be extracted by sending a PR
• as the keys need to be accessed by GitHub actions, store them in a secure way so they cannot be stolen

Thinking about this on IRC, I've come up with a solution that does not feature per-PR, but rather per-repository signing keys. PR authors generate a special key that is only used to sign automated builds. They then add the private key as a GitHub secret. Once they fork, the builds made in their repository can be signed with this special key.

This has some advantages over any per-PR solution. "Per repository" covers "per PR", so the functional requirements are fulfilled. The key could only be extracted by people who can commit into the repository, which limits it to the owner(s), authorized contributors, as well as Team NewPipe, which is a great benefit over alternative solutions.

I don't think there is an easy/good way to generate keys automatically per PR. They would need to be stored in some way, however by default, there is no good solution to do this on GitHub. I was thinking about using some sort of private repository, but configuring such a setup correctly is a lot more complicated than just using repository secrets, which are made for this purpose. Furthermore, I don't think we should add a dependency on any kind of third-party service for this. The secrets are a built-in feature.

Signing with the key from the secrets can be put in a script and run automatically when such a secret is available. This way, once you fork, you just need to generate a key and set up the secret. That's probably less than 5 minutes of work. The only issue I see here is that we need to reiterate over and over again that this key should not be their main key. Once it's stored on GitHub, it is known to one third-party entity already. When filing PRs and allowing edits by maintainers, even more people get access. Also, GitHub stores these in a way so they are recoverable, therefore an attacker might be able to extract them as well.

As mentioned before, building the APKs using a pull_request trigger in our repository does not help with the issue either. Repository secrets are not available in builds triggered by unauthorized people for a reason. We would have to work around this if we wanted to use a repository-wide key. For PR-only ones, we run into that exactly same storage issue. We could set up some service to manage the secrets, but authorizing access to secrets would be relatively complicated. Validating that only PR builds from our repository can access the secrets is not possible, as far as I can see. For instance, sending some sort of signed payload to the build agent which prints it on the console or something like that gives adversaries a small time window to authorize on the service. PR authors can further run any kind of code on GitHub actions, so such a setup cannot be secured without doing some software protection and/or "white-box cryptograhpy" to make sure only binaries distributed by us could access the service... It'd be a mess.

Regarding the links to the built binaries, I guess we'll have to use a third-party system like nightly.link. GitHub actions still enforces a policy to allow only logged-in people to view and download artifacts (and build logs), which nobody really understands and which is really annoying. The default GitHub actions script could however post the public key to allow validating the binaries downloaded via that third-party service. Note that when using this service, we should include a hint to their documentation. They would like every repository that uses the service (which includes forked repositories) to use their GitHub application to reduce the usage of their own API keys.

[litetex]

I am not very familiar with the current topic, however maybe the following will help:

https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows
https://github.com/actions/cache

Technically a cache-identifier/key can be used, which can be based on the current branch.

So the following could be done:

• Check if a cached signing key exists
• if not → create one
• if it exists → use the existing one
• Sign the APK with that key

Sonarlint uses such an approach:
https://github.com/litetex/SWAPS/blob/develop/.github/workflows/sonar.yml#L46-L60

---

However as @TheAssassin stated:

That problem can be solved otherwise, too. You could add a random ID to the APK identifiers, for instance. That would be much easier than fiddling with signing keys.

This looks like a better solution - at least for me.

[opusforlife2]

Anyone aware of any improvements to Github over last year that let us proceed further here?