Add support for registry attributes in `registries.conf`

[TerryHowe]

It seems like it would be convenient to have registries attributes section to capture things distribution spec like support of referrers which kind of has three values yes/no/unknown. That is just one example and I'd think there would be more in the future.

Is there something like that I am missing?

[mtrmac]

Thanks for reaching out.

Configuration files are one of the most stable UIs of this package; I don’t think it makes sense to add new fields there — and commit to any specific semantics, limiting our future options! — if we don’t have any plans to use such fields.

Do you plan to work on any specific feature that would need that kind of data?

[TerryHowe]

I'm working on rregistries.conf support for oras-go](oras-project/oras-go#1008) and I would like a place to capture characteristics of registries.

It seems like it would useful to have an attribute of key value pairs that are ignored if you did not support the characteristic. In toml this would be an inline table. An obvious one would be referrers API support, but it could also be used for irregularities of a particular registry. For example, there are differences in the handling of bearer and basic auth. Maybe something like:

attributes = { referrers = "unknown", bearerAuth = "false" }

[TerryHowe]

Another example of a registry anomaly is OCI container registry doesn't support unicode characters in annotations. I'm not saying I'd code against that one, but these are the kind of arbitrary things where I'd want to change behavior for a particular registry.

[mtrmac]

It seems like it would useful to have an attribute of key value pairs that are ignored if you did not support the characteristic.

How do users use that reliably if they set an unsupported option (or make a typo) and it’s silently ignored?

I think just adding a new field, and having every other software warn if it finds an unsupported field in the configuration would be better. (And c/image sort of does that already — except that the log is only at a debug level, da9dd77.)

That would still benefit from cross-project coordination, of course. Or, I guess, carve out an orasAttributes field, but that would have Podman and friends always warn.

---

In the specific case of referrers, that’s sort of being discussed in parallel in #567 (comment) . If you know of registries that do need, or don’t need, an option, that would be a very useful data point.

Maybe we can design something for referrers, without having to commit to a more general design.

[TerryHowe]

What I was hoping for is:

1. There would be some agreed upon field for attributes/properties whatever you want to call it.
2. If present, it parses as an inline table.
3. If there are agreed upon key/values, there can be optional validations defined.
4. Unknown keys are ignored other than an optional debug print.
5. Implementations may validate certain key/values if they want.

I only really have three use cases at the moment which I kind of talked about

• referrers API support being true/false/unknown (unknown being default)
• force basic or bearer auth (some registries say bearer but work better with basic)
• plain http is attribute no necessarily covered by insecure
• the OCI CR annotation problem (Just and example, no plans to code against this)

I imagine I'll find more anomalies.