Provide a means to configure simple signature lookaside storage.

[sjhx]

If the registry used does not have support the simple signing registry extension then the signatures will need to be pulled from another store.
Portieris does not support host configuration files so we need another way to identify defined signature storage.

[sjhx]

We need to be able to do the equivalent of installing a file in /etc/containers/registries.d similar to:

docker:
  target-registry-domain.com:
    sigstore: https://$USER:@[email protected]/folder/or-other

[sjhx]

We want to do this in a kube native way, (no files!) given that we will be able compute the config dynamically, 'docker' will be constant, the target domain is that of the image under eval, we may be able to think of a way to inject the credentials (use pull secret? any in scope pull secret, need not be the same as the image's), and map from the domain/image to the the rest of the path.

[sjhx]

one way to support this would be to allow "sigstore:" under the "simple:" object in the polcy yaml
attempting to reuse the pull-secret may be a little obscure and complex so we could also allow a sigstore-secret: attribute
assuming the sigstore can be used for multiple repo/digest then it works well, if the sigstore can only be used per repo then it would mandate a policy per repo which would suggest we find another syntax

[molepigeon]

What does the simple client do with the sigstore setting? Does it expect to find the same extension API just underneath the specified URL? So for the example would it expect to find the data at loosely-associated-with-target-registry.com/folder/or-other as specified, or loosely-associated-with-target-registry.com/folder/or-other/extensions/v2/whatever?

I think for the former then that would greatly affect your ability to use wildcard policies. For the latter assuming all repos covered by the wildcard have signatures in the same signature store that's probably fine.

[sjhx]

We confirmed that the url is a base url and is extended by repository and signature number object names so it should not badly affect the ability to wildcard policies, although it does add another component to the set of things defined by the policy entry.
Looking that the implementation it does look like we will have to manufacture a configuration file for the container/image library to read since that is the only interface for it to accept that config. We will need to take care of the concurrency and resource consumption aspects of this.

[sjhx]

It is not the repo specific registry extension API at the sigstore location.

[sjhx]

planning to manfacture a file looking like:

docker-default:
    sigstore: <url from config>

called default.yaml which needs to be in a thread unique folder

[sjhx]

work in progres #111

[sjhx]

In order to keep the policy entries self container we need to make a breaking change to the policy definitioon, trust type unchnaged, since these were only introduced iin 0.6.0 we think this is reasonable, we will bump the versioon to 0.7.0