Are ostree commits booted from a container image able to be gpg-signed?

[cgwalters]

(This message was written by someone else)

I'm currently running ext.rpm-ostree.destructive.cached-sigs which I'm pretty sure checks whether or not an unsigned ostree commit can successfully be signed by checking the journal logs for a cached signature. However, the following code which checks for a signature:

$ rpm-ostree status --json > status.json
$ jq -e '.deployments[0].signatures' < status.json

still outputs null even after the commit is signed with the the following commands:

$ booted_commit=$(jq -r '.deployments[0].checksum' < status.json)
$ ostree gpg-sign --gpg-homedir "${KOLA_EXT_DATA}/gpghome" "$booted_commit" "${TEST_GPG_KEYID_1}"

This makes me think that the signing didn't work and is why the test can't find a cached signature in the logs.

[cgwalters]

This is a complex topic. First, the ostree-container stack does support verifying GPG signatures on ostree commit objects embedded in container images. For example, do this:

$ rpm-ostree rebase ostree-remote-registry:fedora:quay.io/fedora/fedora-coreos:stable

However in the container flow we always end up on a "merge commit" which also contains the container metadata - so the booted state will be a different commit object, and the core ostree (and rpm-ostree) doesn't understand this.

Ultimately, I think the main direction to go here is sigstore - and we want an API to verify the transport signature. This relates to...an issue I can't find that also the podman (c/storage, c/image) doesn't record any information about its verification persistently either.

still outputs null even after the commit is signed with the the following commands:

The problem may simply be that rpm-ostree caches its state, and ostree gpg-sign doesn't end up touching the repository mtime which is a bug.

[lukewarmtemp]

Oh I see. So instead of running ostree gpg-sign, we would use something like cosign sign in ext.rpm-ostree.destructive.cached-sigs when the test detects that the system is booted from a container image?

[cgwalters]

Yes; that said I don't have extensive experience with cosign/sigstore myself.

[lukewarmtemp]

If we use end up using sigstore, it will require a fundamental change to ostree by adding something like ostree cosign-sign and ostree cosign-verify right? (Not just calling cosign in the ext.rpm-ostree.destructive.cached-sigs test)

[cgwalters]

I don't think we want to reimplement those no...signing for sure should happen using existing container tools.

Verification is a bit tricker. We today don't copy the signatures fetched when we pull an image; we may want to add that into the ostree storage.

This topic overlaps a bit with the thread around here openshift/enhancements#1402 (comment)