On 28/07/2019 16:18, Ian Jackson wrote:
What it amounts to is a parallel Merkle tree to the git one, just with a different data format and a better hash.
Not really: it wouldn't need the history tree structure (in Git terms [0], it would be a tree object not a commit object), and if we use tar+sha256 [1], it wouldn't need the hash-per-file directory tree structure either.
The upside is the better hash, but I think our overall risk from thegit SHA-1 problem is (i) still in practice quite low
For attacks happening now, I agree (but am not an expert): my intent in suggesting this was "this is an easy way to have a better hash if we want it", not to take a side on the question of whether we need it.
This may change, but we have the option of implementing this fix then (and if it happens suddenly, temporarily disabling tag2upload to give us time to do so).
(ii) exists in all the other places we rely on git already.
That suggests that working towards requiring the SHA-256 mode of git (which at least sort of exists since 2.21 [2], but I don't know if it's usable yet) might be a better use of effort.
[0] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects[1] needs reproducibility, but simpler than pristine-tar in that we're only trying to create _a_ reproducible tarball (not match one created by upstream) and don't need to compress it (as it can be deleted after hashing - unfortunately tar doesn't obviously have a write-to-stdout option to allow tar | sha256). Reproducible builds suggests tar --sort=name --owner=0 --group=0 --numeric-owner. [2] https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt