On 6/25/24 11:56, Matthias Urlichs wrote:
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.
It's 3rd party in the sense that the person uploading isn't generating
or even signing the source package.
(b) It's not *blind*, given that it's reasonably easy to verify that the
t2u server worked correctly
It's blind because I'm not running it: some infrastructure is.
(reproducible builds are a
very good idea but we're not there yet).
https://isdebianreproducibleyet.com/
IMO, we can consider it is there, and fix the remaining 3.6%, or at
least, exclude these from the discussion and consider they need to be
fixed to be part of the game.
(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.
I expect that the vast majority of DDs are using sbuild on their
laptops. That's somehow sandboxed (in a chroot). Of course, we have no
insurance that it is the case, but maybe we could fix that.
Given these
facts I have to admit that I don't understand why you're so vehemently
opposed to this proposal.
I'm not opposed to tag2upload. I like the idea.
I'm opposed to trusting only a signed git tag in your proposed
implementation, when it has been proven we can do much better.
Cheers,
Thomas Goirand (zigo)
