I will write a more detailed response to Russ's analysis later.
I am behind on getting my packages into shape and I want to concentrate
on that for now.
I do agree with Russ's basic conclusion: we should decide whether to
adopt tag2upload for reasons other than security of the architecture.
Simon> For the "full possession of a key" scenario, the threat model
Simon> is that the attacker *would* have access to the victim's
Simon> private key, and therefore a rational attacker would validly
Simon> sign the upload with that, making it indistinguishable from a
Simon> legitimate upload by the victim
I think this is true for traditional uploads but not for tag2upload.
>> For me, that case and the "xz-utils" case are actually quite
>> pressing matters
Simon> The bottom line is that if the attacker has the victim's
Simon> private key material, then the attacker can do anything that
Simon> the victim can do, because in our key-based security model
Simon> the only way we can authenticate the victim remotely is that
Simon> they have control of their own private key(s),
We also have credentials that are used to log into salsa.
So, for tag2upload, we might find that we had additional mechanisms to
trace an attack because gitlab keeps track of which authenticated user
made a particular push.
I appreciate that in most cases the signatures are stronger, more
distributed credentials than gitlab's logs of who does a push.
But they are parallel mechanisms and a discrepancy between these can
help us detect and trace attacks.
