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. An API that gets the signed data (signed tag) with some metadata (which package, version, target suite, maybe some other bits of d/control, would have to think; parts of that might also be in the tag) would still allow having a single system make the decisions. A downside is that integrity verification and third parties (possibly) verifying the data falls flat. For me integrity verification would be somewhat nice and third parties a bit less interesting (given they can get the tag, compare files and possibly redo what tag2upload does if they also care about .dsc and stuff). We are not very good at doing integrated services though. (Please no RPC via SSH forced commands...) With regard to integrity verification, it's probably not fully clear what one exactly wants there. Joerg's idea to have tag2upload run by ftp-master is related to that: if it was part of the archive, all integrity promises still come from within the archive. (I don't really want to run the service though; outsourcing is probably better.) Arguably we do trust some external services somewhat already (like buildds for binary packages). Ansgar
