fix: Updating policy.json to properly verify images

[gmpinder]

We need to look into some workflow to handle properly verifying images before rebasing on a signed keyless image.

• https://www.mankier.com/5/containers-policy.json#Examples
• https://github.com/bsherman/ublue-custom/blob/main/.github/workflows/build.yml#L181-L191
• https://github.com/sigstore/root-signing/blob/main/repository/repository/root.json
• https://github.com/sigstore/sigstore/tree/main/pkg/tuf/repository/targets

[xynydev]

https://www.mankier.com/5/containers-policy.json#Policy_Requirements-sigstoreSigned

[gmpinder]

After conversations in the ublue discord, we found the following bits of information:

• https://github.com/containers/image/blob/afda0f0452d6b3fe41c99890ddfcff7b91aba123/signature/fulcio_cert.go#L180

    // FIXME: Match more subject types? Cosign does:
    // - .DNSNames (can’t be issued by Fulcio)
    // - .IPAddresses (can’t be issued by Fulcio)
    // - .URIs (CAN be issued by Fulcio)
    // - OtherName values in SAN (CAN be issued by Fulcio)
    // - Various values about GitHub workflows (CAN be issued by Fulcio)
    // What does it… mean to get an OAuth2 identity for an IP address?
    // FIXME: How far into Turing-completeness for the issuer/subject do we need to get? Simultaneously accepted alternatives, for
    // issuers and/or subjects and/or combinations? Regexps? More?

• Functionality for verifying GitHub OIDC isn't implemented
  • Would require some way to verify with email instead
• Request for Sigstore signature verification enhancement and flexibility in cosign verify. containers/container-libs#214 issue already exists for supporting the args that we would use

Further development could go into a workflow in blue-build to update the user's policy.json to allow keypair signed images and to also download the pub file ahead of time so that a user could easily rebase to a signed image.

[gmpinder]

@gerblesh just posted this in the Ublue discord. Something to follow

containers/image#2235

[gmpinder]

Another related issue coreos/rpm-ostree#4272

[jmpolom]

We need to look into some workflow to handle properly verifying images before rebasing on a signed keyless image.

What you're after appears to be completely broken/unsupported by the underlying libraries used. Until Red Hat improves them (or you choose to do so and donate your work to Red Hat -- assuming their maintainers agree to merge your changes) your only option is to use static key files which in my opinion adds so little security as to be not worth the effort.

[xynydev]

which in my opinion adds so little security as to be not worth the effort.

It is also required for secure boot to work AFAIK.

[jmpolom]

which in my opinion adds so little security as to be not worth the effort.

It is also required for secure boot to work AFAIK.

Container signing has absolutely nothing to do with EFI secure boot. At all. Ever.

[xynydev]

Sure, ok, that might be a misconception that I've gotten from somewhere. I could not find much information either way online, and I'm too lazy to test it out lol. Regardless, it's a standard way to add a little bit of security by making it possible to verify that a published image was signed with a key from the maintainer.

[reegnz]

In the meantime, as long as OIDC path is being figured out, could we please have verification with the current signing keys public key files? sigstoreSigned.keyData or sigstoreSigned.keyPath could be used (I'm using those settings in other projects to verify oci container signatures with skopeo and it works fine).

your only option is to use static key files which in my opinion adds so little security as to be not worth the effort.

Hard disagree on this one. Literally all mainstream distros ship static gpg public key files to verify package signatures today.
You do need to make sure that you can rotate the key file during the upgrade process, but it's definitely doable, and widespread approach using key files. 'static' key file based package validation has been the gold standard for linux distros for 30+ years.

[reegnz]

Also see this comment: containers/container-libs#185 (comment)

Quoting the important piece:

We have no ambition to replicate the whole cosign feature / option set.

So I think it makes sense to work on the keyfile-based signature verification as it opens up a wide range of security advantages like being able to mirror the OCI layers in a trusted fashion so we don't have to rely on GHCR-only and have true mirroring for ublue-based distros. The lack of signature verification makes adopting universal-blue in big organizations a true challenge (nobody wants each and every OS upgrade in a big organization to saturate the WAN link when you can just mirror and let clients verify signatures).

[xynydev]

I don't have much to say about the signing / verification part since I don't have expertise in this area, but just popping in to clarify this unrelated point

(nobody wants each and every OS upgrade in a big organization to saturate the WAN link when you can just mirror and let clients verify signatures)

If you have a big organization with the capacity to host an OCI image mirror inside LAN, in my opinion you should just publish your images on that local registry. In fact, you don't need to rely on GitHub at all, it is entirely viable to just host ForgeJo or something and get CI/CD and an OCI registry in the same package, all with a single on-prem server.