On Sunday, June 16, 2024 12:01:31 PM EDT Russ Allbery wrote: > Scott Kitterman <deb...@kitterman.com> writes: > > Yes and no. The difference is that currently, I can download the source > > package and verify it myself. Not just who signed it and with what key, > > but that the signature verifies. I don't need to trust assurances from > > any service. > > No, that's not quite true. You're still trusting assurances from the > uploader's system. The uploader did not, in general, directly check the > artifact whose signature you're verifying; they, and you, are trusting > that the source package construction was done correctly from their working > tree. > > There's been a lot of discussion of the implications of the xz backdoor > for source package construction, but one of the takeaways that I took from > it is to be even less sure of the security of the uploader systems that > are generating our source packages. Imagine if xz had been backdoored to, > say, inject the installation of a malicious maintainer script into source > packages constructed on that system. How long would it have been before > we noticed? The malicious code would have been signed by the uploader and > all the signatures would verify without difficulty. > > Certainly we would have noticed eventually. Probably we would have > noticed before the next stable release. But I'm not at all sure we would > have noticed before a lot of Debian uploader systems were backdoored and > potentially a lot of uploader keys were stolen depending on uploader key > storage practices. And there are probably sneakier attacks that I haven't > thought of.
I agree that there's a risk that what the uploader thought they were uploading and what they actually uploaded are different, but that's independent of tag2upload or not. I also agree there are tradeoffs on all this. In the particular case of source package construction, there's a tradeoff between doing it on a centralized, managed service with a known configuration that is internet exposed versus the variety of unknowns associated with individual developer machines. There are different risks for the end user. Currently dget uses dscverify by default before unpacking a source package. I'm not an expert at all, so I don't have any appreciate for the perceived risks that led to that being the default (IIRC, it wasn't always). I am assuming that wasn't random. I'm not sure how that would work in this new paradigm. > > From the perspective of Debian, the project, that's presumably not > > significant and can be accounted for by updating our tools. From the > > perspective of some Debian users, I'm less certain of the significance. > > I think it would be hugely valuable to have something like a "dgit > verification mode" where you can ask dgit, which already has all the > source package construction logic, to take a tag2uplod-generated source > package, start from the tag object and signature, and reproduce that > source package and verify it. Except for the retrieval of the signed Git > tag, in theory all of that could be done locally. I'm not sure how hard > that would be (this comes back to the question of how difficult it is to > ensure that the tag2upload source construction algorithm is easily > reproducible), but I think something like that would go a long way towards > providing some really interesting security properties. I think this is much more manageable if you assume the whole world uses git all the time for everything and git is the interface, but that's not reality. Personally, I think the ability to interact with the archive to do the verification and not relying on things that are not the archive for the code to verify is an important property of the existing system and I don't think it's feasible to maintain it in a tag2upload world. Maybe that's OK, but I don't think it's nothing and it should be acknowledged as a cost of moving in this direction. Scott K
signature.asc
Description: This is a digitally signed message part.
