Sent from Workspace ONE Boxer
On Jun 17, 2024 6:23 PM, Ansgar 🙀 <[email protected]> wrote: > > Hi, > > On Mon, 2024-06-17 at 14:59 +0100, Jessica Clarke wrote: > > On 17 Jun 2024, at 14:53, Ansgar 🙀 <[email protected]> wrote: > > > 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. > > > Hmm, a signed manifest solves that problem and also adds some integrity > verification and possibility for third parties to check the signature > itself as well. Back to square one: Didier's proof of concept design is much better, as it solves all of the concerns. No need to trust a 3rd party key, packages are signed and identified with the uploader's key, and respect all ACLs. No need to change anything to our infrastructure. Added bemefit: packages must be reproducible to support it. The point it isn't solving: contributors still need to learn how to build *source* packages locally. Is this a problem ? I don't think so: we are talking about contributing to packaging anyways. Isn't this the bare minimum knowledge to expect ? Thomas
