On 25.06.24 10:11, Thomas Goirand wrote:
But to the contrary of what you're saying, that *is not* the problem. The problem is that you're proposing to sign something, and upload something else, signed by 3rd party CI that you're willing us to blindly trust.
(a) I don't think of the tag2upload service as "3rd party". it's (proposed to be) part of our infrastructure and treated as such, including restricted access, security updates, assembling the source in a sandbox, and all that. Just like the binary builders with their somewhat larger attack surface which we happen to also trust.
(b) It's not *blind*, given that it's reasonably easy to verify that the t2u server worked correctly – unlike either a direct source upload (because that doesn't have a git tag in the .dsc file, assuming it's git based in the first place) or our binaries (reproducible builds are a very good idea but we're not there yet).
(c) Right now we trust the act of building a source package by the maintainer, on an insecure computer with random software on it, without sandboxing or an assurance of being up-to-date WRT our security archive, which nobody looks at either during signing or afterwards. Given these facts I have to admit that I don't understand why you're so vehemently opposed to this proposal.
(d) The fix for the "something else" problem seems to be to not upload something else in the first place. Eventually.
We can teach our builders to pull the git tag directly, instead of unpacking a source archive. Can't be that difficult. (Yes I know, famous last words and all that, but seriously: is there any fundamental problem with trying "git clone --depth=1 -b debian/$V https://git.dgit.d.o/${P} ${P}_$V" (*) before falling back to the builder's equivalent of "apt-get source $P=$V"?)
(*) there *may* be a step missing here: you might need to run dgit locally if you don't want to pull the "archive/debian/$V" tag that tag2upload made. If in doubt you can always do both, and verify that they match. On the third hand, if the source is patch-applied anyway (I don't know how common that is going to be), you can just use it as-is — instead of asking dgit to split off patches which you then immediately re-apply. :-/
-- -- mit freundlichen Grüßen -- -- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
