Try signature extensions in registry before using the docker sigstore

[runcom]

Now that the docker:// transport transparently uses the registry extension for signature (in OpenShift), I think it's better to first try to push the signature on the registry before using the sigstore in the default.yaml file.
This came out on fedora, we have a default-docker for /var/lib/atomic/sigstore shipped in the os, but when pushing to the openshift registry which supports signatures storage remotely, I expected to use that instead of the sigstore in the default-docker sigstore.

@mtrmac wdyt? I think we have to first 1) check if the registry support signatures storage, 2) push signatures if it supports them 3) fall back to sigstore if it's not an openshift registry. Right now it's very misleading to have signatures on the host when I expected signatures to be pushed to the registry.

# This is the default signature write location for docker registries.
default-docker:
  sigstore: file:///var/lib/atomic/sigstore
#  sigstore-staging: file:///var/lib/atomic/sigstore

I have to comment the above to push signature to the openshift integrated registry using the docker:// transport.

[mtrmac]

Yeah, from e-mail titled ”docker/distribution extension for signature access—impact on atomic and configuration” on Mar 29:

With #255 and containers/skopeo#322 skopeo will be able to automatically use the X-Registry-Supports-Signatures extension to the docker/distribution API, which is available in OpenShift ≥ 1.5 and later.

With this, OpenShift images with signatures can be accessed using the docker:// transport in skopeo / c/image, i.e. no (oc login) is necessary.

If accessed this way, a “transports.docker.hostname…" policy section is used (whereas the native OpenShift access with atomic: uses a "transports.atomic.hostname…" policy section.

As with any other docker:// location, the sigstore lookaside can still be used if configured; right now, those PRs prefer the lookaside over the native extension (i.e., for any registry, it is possible to use a lookside = the Atomic registry is a perfect drop-in replacement for the upstream registry server). In isolation, this seems reasonable…

… except that we ship a registries.d/default.yaml with default-docker: sigstore-staging: file:///var/lib/atomic/sigstore. Given the above, that effectively disables the write path for writing to X-Registry-Supports-Signatures registries. (I’ve already been bitten by this when writing an integration test and wondering why signing silently does nothing.)

Possible options:

1. Leave it as is, document that users have to drop the default if they want to use OpenShift via docker:// . (Perhaps also some enhancements to (atomic trust)?). Bad because it doesn’t work out of the box.
2. Implement a registries.d/*.yaml directive to say sigstore:native or something like that, so that users can keep the general sigstore-staging default and individually opt out for specific OpenShift registries. Still bad because it doesn’t work out of the box.
3. Change the priority in containers/image so that X-Registry-Supports-Signatures registries always use the API and ignore the lookaside entirely. Bad because dropping in Atomic Registry instead of an upstream one breaks the workflow / requires a config change.
4. Modify containers/image so that using a registry which supports X-Registry-Supports-Signatures and has a lookaside configured always fails, forcing the user to decide. Bad because the configuration is still broken—in even more cases, actually—except that it is now not invisible.
5. Drop the default sigstore-staging configuration. Bad because setting up signing with lookaside requires an extra manual step, and changing the configuration on existing systems could break even more.

Something else?

None of the above seem perfect; is there a better option I am missing? If the above are our only options, I guess my preference would be 3. or 5.

Was that lost?

---

Anyway, I have the (trivial) patch implementing 3 available, if you agree that’s the best thing to do.

[mtrmac]

FWIW, #385 . I don’t have a really strong opinion.

[rhatdan]

@runcom @mtrmac @vrothberg What is the state of this issue? Over two years old can we close it?

[mtrmac]

I think this is still worth doing, but #385 asked for a more complex version which does not exist yet.

[corburn]

Is this issue closed given #385 was resolved by #1035?

[mtrmac]

#1035 did start preferring the use of signature extensions, but it did not implement the per-repo configuration of #385 (comment) ; registries that implement extensions can’t be used with lakeside at all.

Nowadays the long-term direction is to use on-registry signatures, using the use-sigstore-attachments option or possibly native registry API (which, unlike lookaside servers, does not require maintaining extra infrastructure, and more importantly automatically handles authentication and access controls). So, I don’t think adding extra per-repo features to prefer lookaside over the extensions is worthwhile any more; if anything, we should add options that allow storing “simple signing” signatures using the sigstore attachment mechanism.