Am Do., 19. Nov. 2020 um 18:32 Uhr schrieb Peter Stuge <peter@stuge.se>:

Patrick Georgi via coreboot wrote:
> > My argument is solely on complexity, but please don't trust that hash too
> > much.
>
> If I shouldn't trust
> "160000 commit 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot" too much,
> why should I trust
> "040000 tree 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot"
> (where the repo referred to through the "commit" entry comes from the
> very same server)?

Let's say that you've audited the files some time in the past, found
them to be good, and have noted down the hash to catch obvious repo
tampering or changes in the submodule commit, saying to audit anew.

Then you rely on a hash (which one, commit? That's SHA1 of a collection of SHA1s for files, directories and submodules) for your certification.

That's true no matter what kind of object those SHA1s represent.

If you create your own hash for the tree, you can as well create a hash of everything (minus .git which has an unstable representation) which conveniently includes any checked out submodules.

If you later need to re-fetch the submodule contents (maybe in a
local clone into a new directory) then merely the hash is not very
reliable. SHA-2 would be a lot better than SHA-1, which is in turn
a lot better than MD5, but just a hash is a lot weaker than the
original audit.

Which is exactly why git is moving to SHA2 now, but that critique is more one of git, so if you don't trust SHA1, don't use git?

Patrick

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado