Switching quay.io/fedora/fedora-bootc to be built by Konflux

cverna commented

2025-12-02 15:55:31 +00:00

Contributor

Hi 👋, we are moving fedora-bootc builds from Pungi to Fedora Konflux (for example https://quay.io/repository/bootc-devel/fedora-bootc-rawhide-standard?tab=tags&tag=latest))

The Question: Is it acceptable to push these images to quay.io/fedora signed only by the Konflux key (not the official Fedora/RelEng key)? This is our final blocker (https://gitlab.com/fedora/bootc/base-images/-/issues/51#note_2843289127)

Long term we want to have https://github.com/fedora-infra/siguldry/issues/49 but in the mean time it would be great if we could make the switch to Konflux.

Hi 👋, we are moving fedora-bootc builds from Pungi to Fedora Konflux (for example https://quay.io/repository/bootc-devel/fedora-bootc-rawhide-standard?tab=tags&tag=latest)) The Question: Is it acceptable to push these images to quay.io/fedora signed only by the Konflux key (not the official Fedora/RelEng key)? This is our final blocker (https://gitlab.com/fedora/bootc/base-images/-/issues/51#note_2843289127) Long term we want to have https://github.com/fedora-infra/siguldry/issues/49 but in the mean time it would be great if we could make the switch to Konflux.

walters commented

2025-12-02 16:08:29 +00:00

Contributor

As far as I can tell, we have never signed quay.io/fedora/fedora - probably related to the fact that we've never used container-native tooling to build it.

So I don't think this is a blocker actually.

But it would clearly make sense to ensure we're signing it, and also we should move the app base image under this same infrastructure too.

As far as I can tell, we have never signed `quay.io/fedora/fedora` - probably related to the fact that we've never used container-native tooling to build it. So I don't think this is a blocker actually. But it would clearly make sense to ensure we're signing it, and also we should move the app base image under this same infrastructure too.

dustymabe commented

2025-12-02 16:14:01 +00:00

Contributor

IMO for OS updates we shouldn't ship them without some sort of verification.

Application containers are usually sandboxed in some way to prevent the blast radius from a potential exploit so I could see shipping containers there that aren't signed/verified, but I think OS updates containers should require a higher level of security.

For OS Updates we've always had one of the following for official fedora updates (I think):

dnf/rpm: checking individual RPM signatures
ostree repo: OSTree commit signatures + verification
container updates (CoreOS today): OOB GPG signing and signature verification

IMO for OS updates we shouldn't ship them without some sort of verification. Application containers are usually sandboxed in some way to prevent the blast radius from a potential exploit so I could see shipping containers there that aren't signed/verified, but I think OS updates containers should require a higher level of security. For OS Updates we've always had one of the following for official fedora updates (I think): - dnf/rpm: checking individual RPM signatures - ostree repo: OSTree commit signatures + verification - container updates (CoreOS today): OOB [GPG signing](https://github.com/coreos/fedora-coreos-tracker/issues/1969#issuecomment-3251151820) and [signature verification](https://github.com/coreos/fedora-coreos-config/commit/7ef45117dc26580d21fef2a8eee5095d200481be)

cverna commented

2025-12-03 10:40:44 +00:00

Author

Contributor

Just to be clear the images are signed, but using the Fedora Konflux instance key which is not available under https://fedoraproject.org/security

👍 1

dustymabe commented

2025-12-03 14:03:57 +00:00

Contributor

👍 - interested to have someone from releng weigh in here.

kevin commented

2025-12-04 22:59:21 +00:00

Owner

yeah, thats all right from my understanding.

We have also #10624 that no one has yet done about signing container images.

So, if we pushed these images signed by the konflux instance key, would that cause any problems for users? ie, would it yell that they didn't have the key or that it was untrusted or anything? And would there be some way we could (if only manually) let people verify with that key?

But yeah, it would be great to have this working

yeah, thats all right from my understanding. We have also https://forge.fedoraproject.org/releng/tickets/issues/10624 that no one has yet done about signing container images. So, if we pushed these images signed by the konflux instance key, would that cause any problems for users? ie, would it yell that they didn't have the key or that it was untrusted or anything? And would there be some way we could (if only manually) let people verify with that key? But yeah, it would be great to have this working

jcapitao commented

2025-12-05 10:57:36 +00:00

AFAIK it won't yell as the /etc/containers/policy.json allows anything for the docker transport by default.

And would there be some way we could (if only manually) let people verify with that key?

Yes see below the commands to manually check:

PUBKEY=/tmp/konflux-pub.key
# logged into Fedora Konflux cluster
oc get secret -n openshift-pipelines public-key -o json | jq -r '.data["cosign.pub"] | @base64d' > $PUBKEY
# then to verify an image
cosign verify --key $PUBKEY --insecure-ignore-tlog quay.io/bootc-devel/fedora-bootc-rawhide-standard:latest

and one could update its /etc/containers/policy.json accordingly with that Konflux pubkey to verify automatically during the pull.

AFAIK it won't yell as the `/etc/containers/policy.json` allows anything for the docker transport by default. > And would there be some way we could (if only manually) let people verify with that key? Yes see below the commands to manually check: ``` PUBKEY=/tmp/konflux-pub.key # logged into Fedora Konflux cluster oc get secret -n openshift-pipelines public-key -o json | jq -r '.data["cosign.pub"] | @base64d' > $PUBKEY # then to verify an image cosign verify --key $PUBKEY --insecure-ignore-tlog quay.io/bootc-devel/fedora-bootc-rawhide-standard:latest ``` and one could update its `/etc/containers/policy.json` accordingly with that Konflux pubkey to verify automatically during the pull.

dustymabe commented

2025-12-05 15:18:59 +00:00

Contributor

Correct, rather than have users configure the policy I would think we (Fedora) would want to ship a policy that required signature verification for containers from repos we know are signed.

👍 1

jnsamyak added the

labels

2025-12-09 08:53:43 +00:00

ngompa commented

2025-12-10 14:46:13 +00:00

Member

Something shipped in the quay.io/fedora namespace should be using the Fedora key, not some other one. Is there a reason this can't be wired up somehow?

jcapitao commented

2025-12-16 15:26:49 +00:00

If releng offers something like what's described in https://github.com/fedora-infra/siguldry/issues/49#issuecomment-2949889535 then we'd "just" have to wrap this in a Tekton task and chain it to the bootc Konflux release pipeline.

siosm commented

2026-01-26 11:15:41 +00:00

I don't think we should ship official release artifacts signed by the Konflux key as anything produced by Konflux is signed by this key. We should make sure that we have official release artifacts (and only those) signed by the Fedora keys.

siosm commented

2026-01-26 11:23:21 +00:00

But to come back to Colin's point, fedora-bootc images currently published (https://quay.io/repository/fedora/fedora-bootc?tab=tags) are not signed so I'm not sure this should block this.

This discussion should probably happen in the context of a change request, maybe https://fedoraproject.org/wiki/Changes/konflux-atomic-change-proposal ?

Edit: Fixed the missing not in the sentence above.

But to come back to Colin's point, fedora-bootc images currently published (https://quay.io/repository/fedora/fedora-bootc?tab=tags) are not signed so I'm **not** sure this should block this. This discussion should probably happen in the context of a change request, maybe https://fedoraproject.org/wiki/Changes/konflux-atomic-change-proposal ? Edit: Fixed the missing **not** in the sentence above.

walters commented

2026-02-24 15:29:12 +00:00

Contributor

Application containers are usually sandboxed in some way to prevent the blast radius from a potential exploit so I could see shipping containers there that aren't signed/verified, but I think OS updates containers should require a higher level of security.

I agree with the spirit of your point, but note particularly for Fedora-bootc we intend that many use cases actually derive at build time instead of updating directly, so it really is fundamentally much more like the app container image.

Now I hope everyone would agree that we should be building all fedora containers with Konflux and signing them with a Fedora key.

But in the interim I don't see any blockers to changing fedora-bootc over to being shipped via Konflux and dropping the Konflux signature again with the rationale that it matches the app base.

Then we'd cut over to signing both with the Fedora key.

> Application containers are usually sandboxed in some way to prevent the blast radius from a potential exploit so I could see shipping containers there that aren't signed/verified, but I think OS updates containers should require a higher level of security. I agree with the spirit of your point, but note particularly for Fedora-bootc we intend that many use cases actually derive at build time instead of updating directly, so it really is fundamentally much more like the app container image. Now I hope everyone would agree that we should be building all fedora containers with Konflux and signing them with a Fedora key. But in the interim I don't see any blockers to changing fedora-bootc over to being shipped via Konflux and dropping the Konflux signature again with the rationale that it matches the app base. Then we'd cut over to signing both with the Fedora key.

👍 1

siosm referenced this issue from council/tickets

2026-06-09 11:13:08 +00:00

Use "Fedora Atomic" as name for bootable container base images #569

Rows
Columns

Switching quay.io/fedora/fedora-bootc to be built by Konflux #13115