Proposed title of this feature request

Quay supports configurable blob hash algorithms

What is the nature and description of the request?

Support for additional hashes beyond sha256 in blob uploads, tag references, and other places where sha256 digests are used today. Initially, just supporting sha256 and sha512, but possibly with the need to extend to additional registered hashes in the future. I dunno if this is something Quay admins will have opinions on, but if diverging opinions are expected, it could be configurable so some admins could run sha256-only Quay, some could run sha512-only Quay, and some could run either-hash Quay.

Why does the customer need this? (List the business requirements here)

Cryptographic hashes, where it's hard to generate input data that collides with a known hash, don't last forever. For example, NIST deprecated SHA-1 in 2022. Transitioning the hash used in Merkle-tree systems is hard, see Git's ongoing push to transition from SHA-1 to SHA-256. Luckily, the OCI folks thought ahead, and the image spec and distribution APIs use a pluggable registry of known hash functions, which currently includes sha256 and sha512. I expect the initial lift from "assume it's sha256" to "it could be one of these registered hashes..." to be large, and subsequent additions to the hash registry to be straightforward, but I'm not a Quay dev, and may be misunderstanding scope. Removing a hash from the registry might be complicated, since you'd need to drop significant quantities of data, and rehashing Merkle trees invalidates signatures based on the old tree. But luckily, we don't need to get into removal yet, with this RFE, folks pushing images to registries could handle the rehash and repush and resign and all that themselves, without Quay needing to automate it.

Also, as far as I'm aware, everyone's currently happy with SHA-256. I'm creating this RFE because it seems like the pivot from one hash to multiple hashes might take some time, and wanted to get it into the queue for review and design and implementation with plenty of runway before anyone comes around to deprecate SHA-256.

List any affected packages or components.

Quay! And likely a million other components; the container ecosystem has been effectively sha256-only for a long time, and "OCI specs say sha512 too!" don't hold a lot of weight if nobody's using them to call out components that currently lack support.

At least chunked upload, and possibly also other actions, might be blocked on upstream disrtibution-spec work, see distribution-spec#494 and distibution-spec#543, especially this section adding a "digest we expect to generate" query parameter to the POST upload-session-creation endpoint. Although I guess we could get out in front of the spec, if we felt like we were in a hurry, or we thought the proposed spec had very good odds of landing without serious rewrites.