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
Originally posted by alilleybrinker November 16, 2023
The spec currently, in Annex A, opens the possibility of permitting the construction of Artifact Identifiers based on arbitrary alternative methods besides GitOID construction with SHA-1 or SHA-256. I believe this is a mistake and should be removed.
A key strength of the design of OmniBOR is that Artifact Identifiers are independently reproducible. They use well-known and widely-implemented hash functions (SHA-1 and SHA-256) with a well-known construction (GitOIDs). In many cases, projects are already using Git, and so have on hand, via Git itself, an easy way to get the Artifact Identifier of any file with git hash-object <file>.
If custom Artifact Identifier constructions are permitted, then producers and consumers need some way to agree on the construction of those identifiers. For example, if a project decides to use BLAKE3 with no header info in identifier construction, they need some way to communicate that to consumers of the identifiers and manifests they produce for their software. This protocol is left undefined, and thus is left for consumers to figure out.
Consumers are then also put in a tough spot, as they need to in theory support an arbitrary number of identifier constructions. If they consume an OmniBOR manifest based on an unknown construction, they need some way to discover how those identifiers were produced, and their consumption tooling must be augmented to support that identifier construction.
This may be feasible in the case that an organization is producing and consuming only their own software, but that is not a normal use case, and we should expect that even in cases where this is the intent, manifests may sometimes cross to the outside world where they will not be understood or consumable.
I think leaving open this possibility is a recipe for complexity in consumption of OmniBOR manifests for minimal gain and trades off a core goal of OmniBOR that identifiers be independently reproducible.
The text was updated successfully, but these errors were encountered:
alilleybrinker
changed the title
Permitting arbitrary custom hashes as the basis for Artifact Identifiers should be removed.
Define "Mandatory Hashes" and permit additional hashes for Artifact Identifier construction.
Dec 7, 2023
Discussed in https://github.com/orgs/omnibor/discussions/69
Originally posted by alilleybrinker November 16, 2023
The spec currently, in Annex A, opens the possibility of permitting the construction of Artifact Identifiers based on arbitrary alternative methods besides GitOID construction with SHA-1 or SHA-256. I believe this is a mistake and should be removed.
A key strength of the design of OmniBOR is that Artifact Identifiers are independently reproducible. They use well-known and widely-implemented hash functions (SHA-1 and SHA-256) with a well-known construction (GitOIDs). In many cases, projects are already using Git, and so have on hand, via Git itself, an easy way to get the Artifact Identifier of any file with
git hash-object <file>
.If custom Artifact Identifier constructions are permitted, then producers and consumers need some way to agree on the construction of those identifiers. For example, if a project decides to use BLAKE3 with no header info in identifier construction, they need some way to communicate that to consumers of the identifiers and manifests they produce for their software. This protocol is left undefined, and thus is left for consumers to figure out.
Consumers are then also put in a tough spot, as they need to in theory support an arbitrary number of identifier constructions. If they consume an OmniBOR manifest based on an unknown construction, they need some way to discover how those identifiers were produced, and their consumption tooling must be augmented to support that identifier construction.
This may be feasible in the case that an organization is producing and consuming only their own software, but that is not a normal use case, and we should expect that even in cases where this is the intent, manifests may sometimes cross to the outside world where they will not be understood or consumable.
I think leaving open this possibility is a recipe for complexity in consumption of OmniBOR manifests for minimal gain and trades off a core goal of OmniBOR that identifiers be independently reproducible.
The text was updated successfully, but these errors were encountered: