RFC: Prefer X-Registry-Supports-Signatures to lookaside

[mtrmac]

In general, a single server should never have both, so the order mostly doesn't matter. The one place where the difference is important is the ability of lookside to have a global default; if lookaside is preferred, such a global default makes X-R-S-S impossible to use.

The disadvantage of this is that simply upgrading a registry to a server version which supports X-R-S-S breaks any previously configured lookaside for the server.

Fixes #384 (?)

[TomSweeneyRedHat]

LGTM

[TomSweeneyRedHat]

@runcom PTAL

[runcom]

So, this patch effectively prefers the registry extension when supported right? If that's the case, the only broken people are the one who are already using the lookaside with a pre-sig-extension registry and they'll start to use the atomic registry. It's tricky, we could look into the sigstore to see if they're using the lookaside, and if they are, prefer that... Still an hack but maybe better than totally overriding.

[mtrmac]

We could also integrate the two systems, so that lookaside per-repo is prioritized over either X-R-S-or lookaside configured per-host (and having both could be a hard error), which is prioritized over the global default.

That seems clean as far as pure algorithms / correctness goes, but it also feels like more effort, and more importantly more complexity that would have to be documented and understood by users, than this corner case would warrant.

[runcom]

We could also integrate the two systems, so that lookaside per-repo is prioritized over either X-R-S-or lookaside configured per-host (and having both could be a hard error), which is prioritized over the global default.

That seems clean as far as pure algorithms / correctness goes, but it also feels like more effort, and more importantly more complexity that would have to be documented and understood by users, than this corner case would warrant.

so maybe we can just go with this? and document somewhere (TBD) what we did

[rhatdan]

This PR is over a year old, @mtrmac What should we do with it?

[rhatdan]

@mtrmac @vrothberg @TomSweeneyRedHat What should we do with this PR? Should we rebase and move forward or should we close it?

[mtrmac]

Rebased, but #385 (comment) is still outstanding (at least to consider, if not to actually implement).

[vrothberg]

@mtrmac, can we use the registry whenever it supports storing signatures in addition to a potentially configured sigstore? This way, we should remain backwards compatible and would support https://bugzilla.redhat.com/show_bug.cgi?id=1724946. We might want to compare signatures when fetching from two sources.

[mtrmac]

Interesting… that’s clearly safe enough for reading (which is where we don’t have a look-aside default, though). It’s not obviously the right thing to do on writes, where we do, but it might be good enough.

In particular, the OpenShift implementation of X-R-S-S has a pretty low limit on the number of allowed signatures (used to be as little as 3!), so it could cause unwanted failures.

[mtrmac]

(Generally speaking, the current default/preference is mostly just wrong, and we should switch to making the sigstore opt-in for any X-R-S-S registries. Still, the potential for breaking users who rely on the current setup is there.)

[sjhx]

I can only offer tea and sympathy on the "breaks existing" problem however I can say that we are bringing on new users (especially via skopeo) who need to take special care to reset the registries.d settings, most remove or comment out the supplied default.yaml. Progress on prioritising XRSS would help us the experience.

[rhatdan]

Where are we on this?

[mtrmac]

This was done in #1035.