docs: faq entry for multiple digest algorithm support#547
docs: faq entry for multiple digest algorithm support#547rchincha wants to merge 1 commit intoopencontainers:mainfrom
Conversation
Add the rationale (hence the Chesterton's fence) for why we are supporting multiple digest algorithms. Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
rchincha
force-pushed
the
why-mix-digests
branch
from
f54798b to
36c8a9b
Compare
| If the existence check for the blob is done first, an immediate failure will indicate the lack of presence of a blob. | ||
| On the other hand, if the registry needs to perform further work to determine if the blob can be accessed by the mounter, it could create an information disclosure risk, in leaking that presence of a blob with that digest in the registry. | ||
|
|
||
| **Q: Why is support for new digest algorithms being added?** |
There was a problem hiding this comment.
Did we add any new algorithms? sha512 was already on the image-spec list of valid algorithms: https://github.com/opencontainers/image-spec/blob/main/descriptor.md#digests
There was a problem hiding this comment.
support for sha512 in the dist-spec?
There was a problem hiding this comment.
But we don't define the list of supported algorithms in distribution-spec.
| The default digest algorithm for OCI ecosystem has been _sha256_ and it has | ||
| worked well. So why bother with additional digest algorithms? | ||
|
|
||
| There are a couple of reasons (not in any particular order of importance): |
There was a problem hiding this comment.
This is missing that blob uploads may be broken on some registries, particularly for post/patch/put requests. There is also no way to push a manifest with a tag by a client controlled algorithm, which means it's not possible to associate referrers with a tagged manifest unless the default algorithm is used.
| - OCI (v1.1.0 specs) now supports arbitrary artifacts and large artifacts pose | ||
| a performance problem especially with strictly serial hash algorithms such as | ||
| _sha2_-family. Much faster parallel digest algorithms such as _blake3-256_ | ||
| are a viable alternative. |
There was a problem hiding this comment.
This seems unrelated to what we're doing now.
There was a problem hiding this comment.
Perhaps not directly, but more a long-term concern.
| - Existing digest algorithms may be broken in the future and it is prudent | ||
| that we design and accomodate for additional digest algorithms. Doing this _a | ||
| posteriori_ is [much harder](https://lwn.net/Articles/898522/). |
There was a problem hiding this comment.
While true, I don't see this as a key reason to improve support of sha512.
There was a problem hiding this comment.
a goal for moving to 256/512 should be to begin the process of testing additional digests...
There was a problem hiding this comment.
I think that's a good goal, but it's an image-spec goal that we can document with the registered digest algorithms there. For distribution-spec, my focus is on allowing valid image-spec content to be pushed and pulled from a registry.
| Note that the two properties that matter to us are _collision resistance_ (so | ||
| content is uniquely addressable) and _preimage resistance_ (so source cannot be | ||
| guessed from the output hash) |
There was a problem hiding this comment.
These are image-spec concerns. Distribution-spec should only be concerned with accepting image-spec content.
3 participants
Add the rationale (hence the Chesterton's fence) for why we are supporting multiple digest algorithms.