WIP: fix: add image spec option back to attach for expanded compatibility …

[jlbutler]

Fixes #1224

This is a WIP, would like to get opinion from @shizhMSFT @qweeah and others on requiring changes in oras-go or not.

The proposed fix for ECR (and hopefully Gitlab, probably others) is to reinstate the oras client 1.0 behavior which allows the user to specify --image-spec w/ oras attach, in order to allow users to specify using v1.1.0-rc2. This version image manifest was broadly supported by 1.0 registries like ECR. With the default in oras client 1.1 now using v1.1.0-rc4, attach is not longer working for ECR (and likely other registries).

I don't think we can cleanly do this with zero changes to oras-go, because the string vals for the oras client --image-spec option come from oras-go (oras.PackManifestVersion).

I thought about using oras.Pack (as suggested by @shizhMSFT), but I at least need to add v1.1.0-rc2 as a pack manifest version.

Since the RC version support is unstable and will be removed in the future, I'm leaning toward leaning into an oras-go PR (and version bump for oras client), and putting most of the changes to support deprecated image spec release candidates into oras-go, where it can be limited and eventually removed more easily.

See accompanying WIP PR in oras-go for conversation.

Please check the following list:

TODO

• Does the affected code have corresponding tests, e.g. unit test, E2E test?
• Does this change require a documentation update?
• Does this introduce breaking changes that would require an announcement or bumping the major version?
• Do all new files have an appropriate license header?

[shizhMSFT]

We can do something like

switch opts.PackVersion {
    case ImageSpecV1_0:
        return ocispec.Descriptor{}, errors.New("image-spec v1.0 is not supported")
    case PackManifestVersion1_1_RC2:
        return oras.Pack(ctx, store, opts.artifactType, packOpts.Layers, oras.PackOptions{
            Subject:             packOpts.Subject,
            ManifestAnnotations: packOpts.ManifestAnnotations,
            PackImageManifest:   true,
        })
    default:
        return oras.PackManifest(ctx, store, opts.PackVersion, opts.artifactType, packOpts)
}

[jlbutler]

We certainly can, and I'll defer to your preference. I figured we could keep the details out of the client with the initial proposal, but if we'd rather have it mostly in the client, I'll make this change.

I think that still requires a change in oras-go and a dep bump in oras (to add back the RC2 const). But let me know if I am missing something obvious!

[shizhMSFT]

oras attach does not support --image-spec v1.0 as it does not specify the subject field.

[FeynmanZhou]

Can we list all available options (values) of the flag --image-spec?

[FeynmanZhou]

Also, this flag should be marked as experimental since it might be deprecated in the future once all registries upgrade to the latest OCI Spec v1.1.0 (stable) someday.

[jlbutler]

Might users want to use oras push for v1.0 manifests into the future?

[jlbutler]

I've modified this PR to align with feedback, but given the Gitlab registry issue seems unrelated, this looks to potentially be an ECR-only issue related to supporting requirements for client-managed referrers as specified by Image spec 1.1.0-rc2 and not as specified by rc4. Specifically, ECR allows subject field, but not artifactType.

Given fallback support as described by 1.1. release candidates should be OCI 1.0 compliant, I am going to pause this PR (keep it WIP for now) and investigate extending support in ECR.

[TerryHowe]

Still a WIP?

[jlbutler]

I did some testing and after some internal discussions, we are going to allow artifactType on manifests in ECR. So I'll withdraw this PR.

Thanks so much for the support and discussion along the way.