Investigate Container Registry Package Perms for PR Build Image Push

[bsherman]

Over the past year there has been significant (but intermittent discussion) about how we could enable pushing images to GHCR during PR workflows.

Goal

Allowing PR image push would provide two main benefits:

1. most obviously, an image built from a PR could be directly used for testing the results of said PR
2. we could chain jobs in the workflow to build images upon images built in earlier jobs in the workflow, whereas today we are stuck with multi-target Containerfiles which duplicate a lot of effort.

The Problem

Security is the problem.

In a recent discord message, @p5 succinctly explained the problem:

Currently our actions use a single GITHUB_TOKEN secret (abstracted from us) which provides read/write permissions to all registries in that GitHub repo. Any PR has access to this GITHUB_TOKEN, so could in theory overwrite the "production" tags (user-facing tags - i.e. ":latest").

If we had two Quay (or other provider) registries, we can store credentials for each in GitHub Actions. One "production" registry with creds only accessible from the main branch in GitHub, and another "sandbox" registry with creds accessible in PRs.

So a build in a PR will use the sandbox credentials, and the exact same workflow running from the main branch would have access to the prod registry credentials. There's no way for an image built and pushed from a PR would end up in the production registry.

(see: https://discord.com/channels/1072614816579063828/1232031426023526411/1232032080431681628 )

The Solution

I do believe we could accomplish this using GHCR by doing the following:

1. create a test org for GHCR namespacing (we have one ublue-os-test)
2. change all our packages to only allow "Read" by default, even from the Gitflow Actions' GITHUB_TOKEN ( see Configuring package access control )
3. create "production"/"sandbox" (or "test") environment secrets which are PATs providing explicit package write privilege to the respective org (ublue-os vs ublue-os-test)
4. reconfigure workflows to use the environment secret when pushing images

(see further in discord: https://discord.com/channels/1072614816579063828/1232031426023526411/1234222014374609048)