Russ Allbery <rra@debian.org> writes: > Simon Josefsson <simon@josefsson.org> writes: >> Sean Whitton <spwhitton@spwhitton.name> writes: > >>> We did some analysis on the SHA1 vulnerabilities and determined that >>> they did not meaningfully affect dgit & tag2upload's design. > >> Can you share that analysis? As far as I understand, it is possible for >> a malicious actor to create a git repository with the same commit id as >> HEAD, with different historic commits and tree content. I thought a >> signed tag is merely a signed reference to a particular commit id. If >> that commit id is a SHA1 reference, that opens up for ambiguity given >> recent (well, 2019) results on SHA1. Of course, I may be wrong in any >> of the chain, so would appreciate explanation of how this doesn't work. > > I believe you're talking about two different things. I think Sean is > talking about preimage resistance, which assumes that the known-good > repository is trusted, and I believe Simon is talking about manufactured > collisions where the attacker controls both the good and the bad > repository. Right. I think the latter describes the xz scenario: someone could have pushed a maliciously crafted commit with a SHA1 collision commit id, so there are two different git repositories with that commit id, and a signed git tag on that commit id authenticates both trees, opening up for uncertainty about what was intended to be used. Unless I'm missing some detail of how git signed tag verification works that would catch this. > The dgit and tag2upload design probably (I'd have to think about it some > more, ideally while bouncing the problem off of someone else, because I've > recycled those brain cells for other things) only needs preimage > resistance, but the general case of a malicious upstream may be vulnerable > to manufactured collisions. It is not completely clear to me: How about if some malicious person pushed a commit to salsa, asked a DD to "please review this repository and sign a tag to make the upload"? The DD would presumably sign a commit id that authenticate two different git trees, one with the exploit and one without it. /Simon
Attachment:
signature.asc
Description: PGP signature