How to handle gitCommit with sha256 commits
TomHennen opened this issue · comments
@laurentsimon filed this bug in slsa-framework, but we probably need to consider it here too.
Do we need to provide any guidance for dealing with sha256 gitCommits.
I meant to post this here but left it on the SLSA thread by mistake:
I don't know of GitHub's support for this but last I checked, there's a 4 stage transition plan in Git where phase 2 and 3 support both SHA-1 and SHA-256 hashes. I don't know if this thinking has changed elsewhere, perhaps on the ML, because this doc is quite old. I believe on the in-toto side we can update our support for git{Commit,Blob,Tree,Tag} to indicate it could be SHA-1 or SHA-256. Differentiating by length should also suffice for now because a transition plan isn't active, if someone's using a SHA-256 Git repo, it has no interop with SHA-1 repos. When there is interop, we'll know how to identify object equivalence when presented with its SHA-1 and SHA-256 hashes.
Same as git, different length. See https://git-scm.com/docs/hash-function-transition/2.40.0#_object_names:
Objects can be named by their 40 hexadecimal digit SHA-1 name or 64 hexadecimal digit SHA-256 name
We should document this.
Would there be a need for an attestation to reference both the sha1 and sha256 commits simultaneously? If so there might be a problem.
Apparently repos will allow users to use either sha1 or sha256. Since DigestSet uses a map there can only be one value for gitCommit, so generators will have to pick which one to use??
If someone trying to verify a commit matches they'll either need to have both sha1 or sha256 available or be able to read the commit from the attestation and then look it up that way?
Alternatively we could recommend people always use X.
Does that make sense or am I missing something?
Perhaps gitCommit should be replaced with gitCommitSha1 and gitCommitSha256 options so we avoid this altogether.
We can also use that to set policies more easily in future to only allow SHA-256 git repos (without having to check the length for each entry).
My inclination is to keep just gitCommit for simplicity, and in the future add another field (e.g. gitCommitAlt) if we find that we need it.
- It's moot if the attester only supports one hash, e.g. they take the hash as an opaque ID and pass it on. This is probably most attesters.
- It's moot if the consumer accepts either, which is what the git hash-function-transition plan of record is. They have a table mapping one to the other.
- It's only a problem if the attester can support both but has to pick one, AND the consumer only accepts one. Maybe this will happen, but I worry a bit about premature flexibility.