Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error pushing provenance to registry when using setup-buildx-action #97

Closed
bdehamer opened this issue Jan 19, 2024 · 1 comment · Fixed by #98
Closed

Error pushing provenance to registry when using setup-buildx-action #97

bdehamer opened this issue Jan 19, 2024 · 1 comment · Fixed by #98

Comments

@bdehamer
Copy link
Collaborator

bdehamer commented Jan 19, 2024

When attempting to attest an image built using the docker/setup-buildx-action an error is thrown if the attestation is pushed to the container registry:

Image

The error seems to be specific to images built w/ buildx as workflows which do NOT use this action are able to push attestations to the registry without error.

@bdehamer
Copy link
Collaborator Author

bdehamer commented Jan 19, 2024

The difference between images built w/ buildx and those which do NOT use buildx has to do with the format of the image manifest which is pushed to the registry.

When NOT using buildx, if you look-up the manifest for an image digest, you'll find a manifest of type application/vnd.docker.distribution.manifest.v2+json:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "size": 451,
    "digest": "sha256:36677367e7a663e1dac05de746c4eb86ccaa7af896742323676165969df8f4fc"
  },
  "layers": [
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 136,
      "digest": "sha256:9e407b41479a010946c5cb67905a7dba2038d262aa6802cb9bc1b7fbc2c5d433"
    }
  ]
}

In contrast, requesting the manifest for an image built w/ buildx will return a manifest of type application/vnd.oci.image.index.v1+json:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:b1ca86ec409c99af2a214c4f6d2ae132ff8604a8449dc42c8297afc58ac60c10",
      "size": 476,
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:2a742cfed07150b66a5a7ed2f30d1354a1d6b69131350015ee520902ead31fcf",
      "size": 565,
      "annotations": {
        "vnd.docker.reference.digest": "sha256:b1ca86ec409c99af2a214c4f6d2ae132ff8604a8449dc42c8297afc58ac60c10",
        "vnd.docker.reference.type": "attestation-manifest"
      },
      "platform": {
        "architecture": "unknown",
        "os": "unknown"
      }
    }
  ]
}

When attempting to upload an attestation to the registry, the action first checks to see if the image being attested exists in the registry:

async checkManifest(reference: string): Promise<CheckManifestResponse> {
const response = await this.#fetch(
`${this.#baseURL}/v2/${this.#repository}/manifests/${reference}`,
{ method: 'HEAD' }
).then(ensureStatus(200))

If the manifest identified by the specified digest is an index (instead of the plain ol' manifest), Azure will complain unless you specify an Accept header which explicitly identifies application/vnd.oci.image.index.v1+json as an allowed media type.

{
  "errors": [
    {
      "code": "MANIFEST_UNKNOWN",
      "message": "OCI index found, but accept header does not support OCI indexes"
    }
  ]
}

The fix should be as simple as updating this request to include an Accept header which identifies both the manifest AND index media types:

Accept: application/vnd.oci.image.manifest.v1+json,application/vnd.oci.image.index.v1+json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant