tho...@goirand.fr writes: > On Jun 25, 2024 5:50 PM, Russ Allbery <r...@debian.org> wrote:
>> The tag2upload proposal moves the source package build from 1 to 2. > NO ! That is NOT what you are proposing. There's been a 10 years long > effort to have package reproducibility, your proposal is trowing all > away. How does one check the reproducibility of git to source package > transformation? You check it exactly the same way that you check binary reproducibility: you run it twice in different security contexts and see if you get the same results. *If* you're using a regularized transformation of Git to a source package, such as those workflows implemented by dgit (and thus by tag2upload), the problem is at least an order of magnitude easier than binary package reproducibility. > If we were signing source packages manifests locally, then tag2upload > were also producing it, check it is the same as in the pushes tag, and > used the sgnature, then we'd be good. But you don't want this because: > - you feel it is not convenient > - it is hard to implement I think you are excessively focused on making the uploader one of the checks on the reproducibility of the source package. The uploader is does not have unique capabilities for detecting unreproducible source builds. The important point for reproducible source builds is to build the package twice in separate security domains so that an attacker will have great difficulty compromising both builds at the same time. I completely agree with embracing reproducible source builds. That's why I would like more people to use tag2upload or dgit, which regularize the source builds in a way that makes reproducibility testing easier. >> As an aside, I'm not sure there's any ethical way to do this (and any >> way to do this that doesn't result in people panicking about a test), >> but the security person in me badly wants to run a red team exercise >> with reproducible binary builds. If we intentionally introduce a >> (benign) bit of code into an amd64 binary build without anyone involved >> in either reproducible builds or maintenance of that package knowing, >> how long would it take for this to be flagged as a possible compromise? > Are you hereby vouching for reproducibility to become RC bugs? No? None of those words occurred in my message? I'm not opposed to it, but I think the folks working on reproducible builds should be the ones to decide when it's practical for that to be the case. I think we're making some assumptions about the usability of binary package reproducibility for detecting security breaches. Those assumptions sound good in theory, but ideally we would test them. One of the reasons to test them is that those last few percentage points can make a big difference between "huh, this package became unreproducible, probably a bug somewhere" and "we have detected a possible security breach," and I don't know where we are right now in terms of how people would react. > Watch the Kosovo lightning talk where Didier shows what he did. It is a > proven concept. If this is the proof of concept where the *.dsc file is encoded in a Git tag (sorry, there have been several proofs of concept and I lose track of which person was associated with which one), I understand it and have already said why I don't think it will work reliably enough in its current form. (Summary: It relies on the reproducibility of tar and compression programs.) We should measure reproducible source packages by comparing the unpacked source packages. It's a lot more robust. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
