Le jeudi, 13 juin 2024, 08.23:45 h CEST Thomas Goirand a écrit : > One thing I really dislike, is having a single gpg key to upoload them > all. I very much preferred the design that Didier explained during > Debconf Kosovo, where the .changes signature is uploaded together with > the tagged commit.
Thomas is referring to my very rough proof-of-concept with specially-crafted tags I had quickly presented at DebConf22: first lightning talk, video'ed here: https://debconf22.debconf.org/talks/41-lightning-talks/ I had called this "dtag": the idea was to store an inline representation of the .dsc and .changes you would produce locally in `git notes` that get attached to git tags (to avoid storing very large amounts of signatures in a git tag); the uploader pushes the tag, and a job in Salsa CI (or whatever tool) then takes the tag, reconstructs the .dsc and .changes, and then (as they're validly signed), directly uploads them. Source is there: https://salsa.debian.org/odyx/dtag A "signing job" is there: https://salsa.debian.org/debian/libopenaptx/-/jobs/3020729 I never progressed further than the hacked-around scripts I had done towards that lightning talk, mostly for these reasons: * it's fragile: it depends on bit-by-bit reproducibility of source _and_ changes files between what the uploader would do on their machine, and what the git tag notes processor does. As the dgit & tag2upload teams have demonstrated, there are _many ways_ this can (and will) break. * while I like the "only upload if the CI passes" feature, I'm not very happy with the fact that as uploader, I already granted the right to upload (as all the material to generate a signed source package is pushed) before the CI ran successfully: an evil bypasser could use my git tag+notes and upload anyway, as signed with my key. I don't think its unique to that implementation though: all signed processes around git tags have the same issue. * Debian has fallen behind in my priorities, so I'm uploading less, and polishing this has not been on my todo list. * generating the special git notes is bulky, and requires local software, that is not-pretty python3. By no means do I claim ownership of the idea or the design, or even on the proof-of-concept code; if that is seen as worthwhile, I'd be honoured to see anyone building on top of this idea, design, or code! -- OdyX
