You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: faq entry for multiple digest algorithm support
Add the rationale (hence the Chesterton's fence) for why we are
supporting multiple digest algorithms.
Signed-off-by: Ramkumar Chinchani <[email protected]>
Copy file name to clipboardExpand all lines: FAQ.md
+23Lines changed: 23 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -81,3 +81,26 @@ If the client is trying to be defensive to nonconformant registries, and receive
81
81
Mounting without having to specify `from`, also known as automatic mount origin discovery, requires the registry to determine whether or not a blob exists in any repository.
82
82
If the existence check for the blob is done first, an immediate failure will indicate the lack of presence of a blob.
83
83
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.
84
+
85
+
**Q: Why is support for new digest algorithms being added?**
86
+
87
+
The default digest algorithm for OCI ecosystem has been sha256 and it has
88
+
worked well. So why bother with additional digest algorithms?
89
+
90
+
There are a couple of reasons (not in any particular order of importance):
91
+
- Existing digest algorithms may be broken in the future and it is prudent
92
+
that we design and accomodate for additional digest algorithms. Doing this _a
93
+
posteriori_ is [much harder](https://lwn.net/Articles/898522/)
94
+
- OCI (v1.1.0 specs) now supports arbitrary artifacts and large artifacts pose
95
+
a performance problem especially with strictly serial hash algorithms such as
96
+
_sha2_-family. Much faster parallel digest algorithms such as _blake3-256_
97
+
are a viable alternative.
98
+
99
+
Note that the two properties that matter to us are _collision resistance_ (so
100
+
content is uniquely addressable) and _preimage resistance_ (so source cannot be
101
+
guessed from the output hash)
102
+
103
+
The guidelines being followed when making this change are:
104
+
- An artifact (including container images) may be composed of one or more digest types.
105
+
- An artifact registry must not modify an artifact once pushed.
106
+
- An artifact registry must be able to reject unsupported digest algorithms as early as possible during push operation.
0 commit comments