Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define "Mandatory Hashes" and permit additional hashes for Artifact Identifier construction. #74

Open
Tracked by #73
alilleybrinker opened this issue Dec 7, 2023 Discussed in #69 · 0 comments · May be fixed by #81
Open
Tracked by #73

Define "Mandatory Hashes" and permit additional hashes for Artifact Identifier construction. #74

alilleybrinker opened this issue Dec 7, 2023 Discussed in #69 · 0 comments · May be fixed by #81
Labels
c-spec Category: Improvements or additions to the OmniBOR specification

Comments

@alilleybrinker
Copy link
Member

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.

@alilleybrinker alilleybrinker added the c-spec Category: Improvements or additions to the OmniBOR specification label Dec 7, 2023
@alilleybrinker 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-spec Category: Improvements or additions to the OmniBOR specification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant