Get digest before push

[griffin]

👋
I wanted to see if the project was open to adding a cli command and a library function to get the digest of an artifact before pushing. We have some bazel rules that use ORAS to create custom artifacts and then output the digest, but we have have to do this in a reproducible way without network access. Bazel's rules_docker does something similar to this.

It seems as though I could adapt some of the code here to do this, but I wanted to get a feel for this feature before I started implementation.

[SteveLasker]

Interesting. @shizhMSFT, what do you think?

[griffin]

I've written an internal patch to do this, extending the push command with a --dry-run flag.

A better design may be introducing a primitive digest command, but it requires abstracting part of the push command as it has a lot of the same logic. I would like to confirm a plan before undertaking any larger work.

[SteveLasker]

We've had a few recent conversations about how we might achieve this. For example, the notary v2 efforts require a manifest to sign, which requires a digest.
I think there's an interesting set of factoring questions here
Should ORAS include

• digest generation libraries?
• manifest creation, without having to push to a registry first?

Open to discussion from other maintainers (@jdolitsky, @shizhMSFT, @jzelinskie, @vbatts, @sajayantony)

[shizhMSFT]

A dry run for manifest generation is interesting. Once, we have manifest, we can compute the manifest digest and sign it using notary v2 later.

[SteveLasker]

@griffin - you might want to checkout https://github.com/deislabs/oras/tree/prototype-2
@shizhMSFT added the --dry-run support, along with --export-manifest as part of the Notary v2 prototype work.

If we like, we can promote it up to main, but I do want to give credit for your suggestion.

oras push localhost:5000/foo:bar \
  --dry-run \
  --export-manifest manifest.json \
  sbom.json

cat manifest.json

Output:

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.unknown.config.v1+json",
    "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
    "size": 2
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:b0a764ebc678d8614c9c05e2fef857b9bf0673ed3e66a6cec0a14540942e7ad4",
      "size": 101,
      "annotations": {
        "org.opencontainers.image.title": "sbom.json"
      }
    }
  ]
}

And, new experimental reference artifact support

oras push localhost:5000/foo:bar \
  --artifact-type application/x.sample.doc.v0 \
  --dry-run \
  --export-manifest manifest.json \
  sbom.json

cat manifest.json

Output:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.artifact.manifest.v1+json",
  "artifactType": "application/x.sample.doc.v0",
  "blobs": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:b0a764ebc678d8614c9c05e2fef857b9bf0673ed3e66a6cec0a14540942e7ad4",
      "size": 101,
      "annotations": {
        "org.opencontainers.image.title": "sbom.json"
      }
    }
  ],
  "manifests": []
}

[shizhMSFT]

This issue can be resolved once #378 is resolved.

That is, push to an OCI layout, and then get whatever we want to do further process. Finally, do oras copy from the OCI layout to the remote registry.

[qweeah]

Closing as it's covered via oras push/attach --oci-layout in main branch.

@griffin You may use a local folder test to stage the manfiest before pushing it to a remote registry. Try below commands:

oras push --oci-layout ./test:v1  foo bar # pack file `foo` and `bar` into an artifact tagged with `v1`
oras manifest fetch --oci-layout ./test:v1 --descriptor # fetch the descriptor of the generated manifest (digest included)
oras copy --from-oci-layout ./test:v1 <your.registry>/<repo>:v1 # uploading the artifact to remote registry

You need to build from main branch. This feature will be included in oras 1.0.0-rc.1 release planned for end of Jan 2023.