Re: [RFC] General Resolution to deploy tag2upload
On 17 Jun 2024, at 14:53, Ansgar 🙀 <ansgar@43-1.org> wrote:
>
> 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*".)
Would an API for tag2upload to use satisfy that concern? It feeds in a
source package name and key fingerprint (or the signature, or
whatever’s deemed useful), dak replies whether it’s valid for
uploading. Then you don’t need to trust tag2upload’s authorisation
checks beyond that it adheres to what dak says each time.
Jess
Reply to: