If you have a source package already compiled locally to be manifested/signed, then why are you not just uploading that? This assumption completely removes the point of tag2upload.
There are plenty of valid use cases that do not create a dsc locally. Or wouldn't if it wasn't required for upload. The whole point is that dsc package is *not* source. It is not the format most commonly used for development work. It is an intermediate software generated artifact. I can not imagine develplopers regularly manually inspecting contents of their generated dsc packages before signing them to make sure that source in files there match the files in their work dir. Developers signing a git tree state is far closer to developer signing the *actual* artifact that they are working on, inspecting and modifying. Everything after that: dsc, deb, Packages.gz, Release.gz are generated from that actual source tree and can be handled by appropriate automation. Nothing technically prevents dak simply looking at tag2upload field/file specifying the uploader key and reject the upload if that key is no longer valid by the time the dsc makes it to the dak. Or reject the deb upload for buildd if the original uploaders key is invalid by the time arm64 buildd has finished building the source-only upload they pushed yesterday. People loosing access is quite rare, so it doesn't hurt to make these checks multiple times and reject as soon as one check fails. Just because one system accepts the package for processing, does not mean that another system down the line can't reject it, especially when key criteria changed in the meantime. On Mon, 17 Jun 2024, 23:07 , <tho...@goirand.fr> wrote: > > > Sent from Workspace ONE Boxer > On Jun 17, 2024 6:23 PM, Ansgar 🙀 <ans...@43-1.org> wrote: > > > > Hi, > > > > On Mon, 2024-06-17 at 14:59 +0100, Jessica Clarke wrote: > > > On 17 Jun 2024, at 14:53, Ansgar 🙀 <ans...@43-1.org> 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 > > >
