Accept URI for Sigstore Signed Images

[lukewarmtemp]

Fixes coreos/rpm-ostree#4272 (comment)

Allows for container images signatures with a URI instead of a email
address as the SAN. This is needed in certain cases such as using a github workflow to sign a container using the github actions OIDC token.

The URI field was added to the fulcioTrustRoot struct and associated functions were modifed/created. Logic to handle either having a URI or email address as the SAN was also implemented.

Testing:

1. Copy and store fulcio_v1.crt.pem to /etc/pki/containers/fulcio.sigstore.dev.pub and rekor.pub to /etc/pki/containers/rekor.sigstore.dev.pub, both of which can be found at: https://github.com/sigstore/root-signing/blob/main/README.md

2. Configure /etc/containers/policy.json

{
  "default": [
    {
      "type": "reject"
    }
  ],
  "transports": {
    "docker": {
      "registry.access.redhat.com": [
        {
          "type": "signedBy",
          "keyType": "GPGKeys",
          "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
        }
      ],
      "registry.redhat.io": [
        {
          "type": "signedBy",
          "keyType": "GPGKeys",
          "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
        }
      ],
      "ghcr.io/jmpolom": [
        {
          "type": "sigstoreSigned",
          "fulcio": {
            "caPath": "/etc/pki/containers/fulcio.sigstore.dev.pub",
            "oidcIssuer": "https://token.actions.githubusercontent.com",
            "URI": "https://github.com/jmpolom/fedora-ostree-ws-container/.github/workflows/build.yml@refs/heads/main"
          },
          "rekorPublicKeyPath": "/etc/pki/containers/rekor.sigstore.dev.pub",
          "signedIdentity": {
            "type": "matchRepository"
          }
        }
      ]
    },
    "docker-daemon": {
      "": [
        {
          "type": "insecureAcceptAnything"
        }
      ]
    }
  }
}

3. Create /etc/containers/registries.d/ghcr.io.yaml

docker:
     ghcr.io/jmpolom:
         use-sigstore-attachments: true

4. Build the skopeo binary and run the following

$ ./bin/skopeo copy docker://ghcr.io/jmpolom/fedora-silverblue-ws:38-main dir:/some/local/directory

[lukewarmtemp]

Hello @mtrmac, this is a small patch I've made to the sigstore verification process in order to address the issue linked in the PR message. I was wondering if you could both review my PR and offer some insight on some next steps/ways to generalize the patch so that we can catch more bugs related to sigstore from coming up down the line.

[cgwalters]

Thanks for working on this!

Without digging into the details, I think (unless I'm misunderstanding something here) this should be a PR against https://github.com/containers/image - any changes to the vendored sources here would be lost when updating.

BTW a common thing when developing Go is to use the replace directive so that you can build a skopeo binary with your changes to the vendored library for integration testing.

[mtrmac]

Thanks!

• Yes, this needs to be a PR against containers/image, not against Skopeo . Please file one and we’ll continue there.
• I’m not immediately sure the URI field is the one we should target. Can you post the full openssl x509 -text of the generated certificate, please? https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#directory documents various more specific fields, maybe this should actually target one (or more?) of them. OTOH just matching on SubjectAltName URIs might be more general. I don’t have a strong opinion so far.
• For c/image/signature, it would also need unit tests with close-to-perfect coverage (both of the policy parsing and implementation/enforcement).

[mtrmac]

• ⚠️ If the policy requires both an email address and an URI, this must not accept signatures which only have one of them
• This is invoking slices.Contains(…, "") if the field is not set. That’s at the very least unclean.
• I suspect the error reporting logic should also be tightened. It must primarily decide based on the policy, not on attacker-set untrusted* fields.

[jmpolom]

If the policy requires both an email address and an URI, this must not accept signatures which only have one of them

I believe this would be an invalid policy with cosign. One or the other. A signed container won't have all the OIDs from my experience it will have a subset based on whether it was signed via the interactive cosign workflow or keyless method.

[mtrmac]

Then such an invalid policy must be rejected at parsing/initialization time, not processed in an unexpected way.

[mtrmac]

This is silently ignoring the options if both are specified?!

[lukewarmtemp]

Moved to containers/image#2235