Bastian Blank <wa...@debian.org> writes: > On Tue, Oct 29, 2019 at 12:19:03PM -0700, Russ Allbery wrote:
>> Could you help me understand what this would look like? Is it something >> like this workflow? >> >> 1. tag2upload determines the local Git tree that should be uploaded as a >> new source package. >> >> 2. tag2upload locally constructs a source package from that Git tree. >> >> 3. The uploading user signs the source package that tag2upload constructs. > The uploading user signs the .dsc file that was constructed. Ah, okay, so the idea is to either embed the full signed .dsc file in the tag or to embed at least the signature (and have the server reconstruct the corresponding .dsc file)? >> 4. tag2upload pushes a rich tag to its upload server that contains enough >> information to identify the Git tree that should be uploaded and that >> includes the signature over the source package constructed from that >> tree. >> >> 5. The tag2upload server reconstructs the source package from Git, >> attaches the signature, and then forwards both to dak. > The server reconstructs the source, attaches the signed (by the user) > .dsc file and signs the .changes file covering the whole upload itself. Aha, I think this is new: dak would then be willing to accept a .changes file signed by the tag2upload server as long as (I'm assuming the rules here, please check) (a) this is a source-only upload, and (b) the .dsc file is signed by a DD or DM. And then the upload permission check would be done against the identity of the .dsc signer rather than the .changes signer? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
