>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
>> 2) Attacker possibly through a compromise of the dgit server and
>> salsa changes the git view to be something harmless.
Sorry I was assuming that the web ui and the git repository were still
consistent, but were inconsistent with what was uploaded to the
archive.
I.E.
t =0 attacker uploads something undesirable through tag2upload.
t=1 attacker convinces salsa and dgit to replace that git tree with a
tree that is not undesirable and that has the same hash (so signatures
still verify).
If you look at git, everything looks fine.
If you clone git or dgit, everything looks fine.
If you look at the archive you still see the undesirable code.
I had not considered having the web UI diverge from the git tree. I
think that is entirely unrelated to tag2upload, although I agree it is
scary.
I didn't want to specifically talk about hash collision because there
might be other ways to create similar situations.
However, I think your comment about tag2upload not making this worse may
still apply.
In particular, today it's obvious that I don't need to upload sources
that differ from what I push to salsa (if I do not use dgit).
The only way in which tag2upload really comes into play is that it
increases dgit use and increases the probability that people will assume
looking at salsa|dgit is the same as looking at the archive.
And as we've discussed here, that may or may not be true.
Again, I'm really sorry I'm still not finding time to be thorough about
this.
I got krb5 into shape last week.
There's one free software task (thinking about the OSI AI definition
discussion) that is ahead of actually spending time on tag2upload on my
queue.
