Sent from Workspace ONE Boxer
>
> Hi,
>
> On Mon, 2024-06-17 at 14:59 +0100, Jessica Clarke 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