Hi there ! o/
On Jun 17, 2024 11:11 PM, Aigars Mahinovs <aigar...@debian.org> wrote: > > 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. Well... I see no point in tag2upload anyways, I'd probably use it but still think it is a gadget, because it doesn't take long to build, check and upload. I am saying this though doing a lot of uploads per year (2000+). But since you ask... Absoluetly not! Building a *source* package takes a few seconds: building all binaries takes much longer, but you don't need to build them localy, that is the whole point: we upload source only these days. So, build the .dsc, the .changes, include them in the signed taged commit, and let the CI do the rest. > There are plenty of valid use cases that do not create a dsc locally. Please be specific in why it is unacceptable to have a local tool do local (very quick) computation in a full automated way for you. Why is this unacceptable? > 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. What point are you trying to make here? A .dsc is metadata for the upload indeed, just like the .changes. Then what? Why should you care if a local tooling on your laptop is building it, adding it to the signed tag, and maybe (optionnaly) deleting your local copy after sending it to Salsa CI for the upload? > Everything after that: dsc, deb, Packages.gz, Release.gz are generated from > that actual source tree and can be handled by appropriate automation. Have you ever created a .dsc file by hand? I suppose answer is no. So what is the trouble ? Or are you saying I am proposing to do that ? I suppose no as well. So what bothers you? :) That your laptop need to calculate the hash of your debian.tar.xz when tagging? Isn't this a very small deal to make, so we don't need to touch a bit to our infrastructure, auth and ACLs? Plus having no "a single key to sign them all" would be an awesome feature. Also, with my Salsa admin hat on: I do NOT trust Gitlab security track record enough to give it the right to upload for everyone. Do you? Everyone voting for such implementation will be held accountable for such later possible hack... > 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. Are you hereby volunteering for such (dak and other) work? Plus the DM ACL thingy? Plus things you didn't think of? If not you, then who? Do we have patches available or at least a known team of volunteers? Cheers, Thomas Goirand (zigo)
