Create a Github-hosted PPA for Jamulus

[pljones]

Background

x64 Linux users with distributions based on Debian currently need to download and install the .deb file manually from each Release of Jamulus if they want to keep up to date. This is because most of the Debian-based distributions are falling behind the Release version, as they're only maintained on a best-endevours basis.

The usual mechanism used in cases such as this is a Personal Package Archive (PPA) referencing the software. This allows the user to keep the software update using the built in tools for their distribution.

Proposal

It is possibly to maintain a PPA directly on Github. The process is explained by Assaf Morami here. It assumes that a single Github user account would maintain the PPA but I am proposing that the PPA for Jamulus be "owned" by the Jamulussoftware organisational account. The release workflow would take place as is, ending up with a new tagged release. This would then need to trigger (ideally automatically) a workflow in the PPA repository to pick up the release .deb file(s) and add them to the PPA.

This would require a GPG key to be created on behalf of the account by a "trusted party" and then secured such that only the Jamulussoftware account and any Github accounts trusted to manage that account had access to the private (signing) key. Any existing Jamulussoftware account Admin could create the GPG keypair for Jamulussoftware. Each Admin would also need provide their GPG public key to the key creator so that they could received an encrypted copy of the keypair that only they could import.

(There's also fluff around key-signing keys and key revokation that would need thinking about.)

Github has provision for such secrets. We could use a repository-level secret that is recognised only as the signer for the PPA repo.
https://docs.github.com/en/actions/security-guides/encrypted-secrets

There is a market place action to bring the secrets into the workflow.
https://github.com/marketplace/actions/import-gpg

[ann0see]

Great idea! Actually I also thought about this, but failed due to the lack of knowledge in the automated setup.
A few thoughts:

This would then need to trigger (ideally automatically) a workflow in the PPA repository to pick up the release .deb file(s) and add them to the PPA.

I'm unsure if it's possible to link two repositories with GitHub actions. I think you could probably push from the main repo to the PPA repo by using a bash script. So the workflow would look like that:

1. Push tag to GH (maindev)
2. Autobuild deb
3. git push deb to PPA repo (the "automated" step)
4. On the PPA repo a GH actions script would run (since it received a push) and rebuild all the files necessary to build update the PPA
5. The new release would be accessible via the PPA

Concerning the signing, someone who is deeper into this topic should have a look at it (@hoffie)?

[gilgongo]

Apologies, what I meant when I said "What next?" was what exactly is next? Shall I create a repo under the org? Are GH "secrets" the same thing as key pairs? If so, what do we/I/you need to do now? Etc. :-) In short: how can I help?

[pljones]

All I've got are what's in the items I've linked. Unfortunately, there's no organisation example that I've found, so one thing to work on would be to see if something like that exists anywhere and I just missed it.

[gilgongo]

Oh OK. Does the PPA for Jamulus definitely need to be "owned" by the Jamulussoftware organisational account, or can we just have a signing key for the PPA repo? When I tried setting up a GH action to put new issues and PRs from more than one repo automatically into the project we have, organisation permissions seem extremely hard to work out (in fact I gave up, and so did the various people who tried to help from the market place scripts I was using).

[hoffie]

I say, if you've access to your Github account to put a pubkey on it, you're trusted enough to push releases out the door as it is, so what further verification is needed?

I agree. The purpose of the GPG signing in this case is proof that the packages come from us. While signing the team key with our individual keys would certainly be nice, I don't think it should be a requirement. Providing a simple repo and the relevant pubkey via https from one of our established places (= Website, or Github directly) should be sufficient to provide the same level of trust and security which we have for ordinary release downloads.
What we do have to think through though is GPG key lifetime and possibly key rotation procedures.

I think repo creation is perfectly doable. There are lots of examples, scripts and actions, although lots of it seems dated and possibly unmaintained.

As far as I can see, there are currently two approaches for hosting such a repo:

1. Github Pages
2. Github Releases

Pages sounds more natural to me (possibly because it most closely resembles "just a webserver", which would be needed when doing things manually).

Regarding triggers, I see the following options:

1. Build the repo as part of the jamulus repo and upload it as artifact there or publish it as Github page from there. This way, GITHUB_TOKEN should work.
2. Use a separate repo for the workflow and the contents. GITHUB_TOKEN will not work there as it is bound to the source repo.
   a. We can either use a machine account (a regular Github account) with appropriate permissions and a matching Personal Access Token,
   b. We can create a synthetic Jamulus Github App (as pointed out by @dtinth, thanks!): https://github.com/peter-murray/workflow-application-token-action or
   c. We can push the button manually (workflow_dispatch). The latter may sound non-optimal wrt automation. However, lots of roll-out strategies include rolling out to a small subset of users first. So maybe it would not be a bad idea at all to start publishing via repos only a few days after the official release in order to give the final release some real world testing by non-repo users?

I may have some time to do further tests regarding this topic and will report back here.

[dtinth]

I think it's also possible to start from (c), then add in either (a) or (b) later.

For example:

1. Create a ppa repo to store the .deb files.
2. Create a manually-triggered GitHub Actions workflow that generates Packages, Packages.gz, Release, Release.gpg, InRelease files and push it to gh-pages branch, thus publishing the ppa. Everything happens within the repo, so $GITHUB_TOKEN works out-of-the-box.
3. To automatically release, the jamulus repo can use benc-uk/workflow-dispatch action can be used to trigger a workflow on the ppa repo.

To ensure integrity of dependencies, can do one of two things:

• Depend on a specific hash, i.e. uses: benc-uk/workflow-dispatch@4c044c1613fabbe5250deadc65452d54c4ad4fc7 # v1.1.0
• Fork the action into Jamulus’ org and use that instead, i.e. uses: jamulussoftware/workflow-dispatch@v1

[ann0see]

Just found reprepro: https://salsa.debian.org/brlink/reprepro/-/blob/debian/docs/short-howto the package seems to be quite interesting (and not too difficult to implement). I mean at first, we could provide a beta, un-signed PPA.

[pljones]

I tried to read the "short-howto" but it left a lot of unanswered questions without direction to where to get the answers... I guess if you already know what it's talking about, it might make more sense.

[ann0see]

Yes, it seems a bit confusing, but as far as I read we‘d need to create a configuration file, import a GPG key (using the action you mentioned) and that’s it.

This German wiki site is maybe also interesting https://wiki.ubuntuusers.de/reprepro/

[ann0see]

Hoffie did some work on https://github.com/hoffie/jamulus-repos and I've imported + changed his repo and pushed it to https://github.com/jamulussoftware/repos/

There's also a slightly different approach I'm thinking of in jamulussoftware/repos#2

In short: Change the autobuild process to upload the metadata files directly to the latest release after they are finished and rely on GitHub redirects. The Repo URL would be e.g. https://github.com/jamulussoftware/jamulus/releases/latest/download/

[ann0see]

Ok. My approach is now here: #3013 (including work by hoffie)