blue-build
fix: Updating policy.json to properly verify images
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
https://www.mankier.com/5/containers-policy.json#Policy_Requirements-sigstoreSigned
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
- https://github.com/containers/image/issues/2027 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.
@gerblesh just posted this in the Ublue discord. Something to follow
https://github.com/containers/image/pull/2235
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.
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.
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.
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.