Hi,
On Mon, 2024-06-17 at 08:30 +0200, Matthias Urlichs wrote:
> On 17.06.24 00:04, Joerg Jaspert wrote:
> > Still, we should find a way to keep the existing property of verifying
> > what the uploader signed to upload *without* requiring a third-party
> > $something to be available.
>
> Verifying what the uploader signed is simple enough, it's a git tag. You
> fetch it and verify that the hashes match ("git fsck"; current git is
> hardened against SHAttered) and that it's signed by the correct key.
That's not usable though to match to what dak gets.
> You want to verify t2u's work? Simple enough, run dgit and compare to
> whatever t2u sent you. No $something required.
No, I just want it not to duplicate authentication and authorization in
incompatible ways. Sadly tag2upload developers explicitly do not want
that.
> Oh wait, t2u isn't even "third party". It's a Debian tool running on
> properly-administered (we assume) Debian hardware, running just another
> build step in a sandbox.
It's a third party that would accept uploads that dak would reject for
security and/or policy reasons (including security critical ones); that
is not easily fixable if tag2upload is deployed as is (and the
developers have indicated that they do not want to change that).
It essentially introduces an alternative authentication system (and
authorization system as tag2upload seems to care about DM status) that
*replaces* the one in dak *and* *disagrees* it. Even when you fix one
of the instances where the systems disagree, the basic problem remains
(~> at least technical debt). It is very bad design to have multiple of
these for a single system as you significantly increase the attack
surface (and one of these usually ends up with less maintenance than
the other). (Only one of the systems has to allow the upload, i.e., a
big "*OR*".)
*Additional* authentication or authorization do not have this issue. So
tag2upload can do whatever checks it wants, but dak has to accept the
upload as well (i.e., a big "*AND*").
(A different example: you wouldn't want to accept a package in Debian's
Packages index if only the md5sum matched, but sha1 and sha256 differed
even though some would argue that md5 is still strong against preimage
attacks and fine to use. You use either the strongest hash (though
people would probably disagree which one that is; it could be the SHA-
1-derived hash in Git after all...) or require all of them to match.
You might even drop all other hashes after a transition period.)
So the question really is "should we have multiple disagreeing
authentication and authorization systems that accept uploads to the
Debian archive?" Ftp-masters say "no", tag2upload developers say
"yes".
Ansgar
