Thomas Goirand <z...@debian.org> writes: > On 6/25/24 11:56, Matthias Urlichs wrote:
>> (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. The 1st party vs. 3rd party language is always murky, and I'm not sure how useful it is. (For example, who is the 2nd party? Isn't the Debian archive and its surrounding machinery 2nd party, not 3rd party?) I think a better way of framing this is that there are three entities already involved in uploading a package to Debian: 1. The uploader, who is affiliated with Debian but in the typical case does not have access to any of the Debian infrastructure. 2. The Debian infrastructure itself: dak, buildds, the archive, etc. 3. Some random end user or downstream tool that wants to use the package. The tag2upload proposal moves the source package build from 1 to 2. I am old enough to remember when nearly all i386 builds were done by 1 and we decided to move them all to 2, so to me this is previously trodden ground and some of the reasons why we did that for binary packages also apply here. > It's blind because I'm not running it: some infrastructure is. It's blind in the same sense that the amd64 buildd is blind. There are a bunch of logs that you can go look at if you want to, but people generally won't unless they think there's some sort of problem. > 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. 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? We have a lot of good reasons to believe that this is an excellent way to detect certain attacks, but so far as I know, we've not tested it. It would be very interesting to do that! (Maybe this has already been done and I just didn't know about it?) > I expect that the vast majority of DDs are using sbuild on their > laptops. I would be stunned if this were the case. I am, and it was not trivial to set up, finding the right instructions took me a bit, and I am dubious that many people bothered. None of the people whose packages I've sponsored have ever used sbuild so far as I know. Also, source package builds generally aren't done inside sbuild if I remember the architecture correctly. (Which I might not; please correct me if I have this wrong.) My recollection is that the source package build is normally done outside sbuild and then copied into it. > I'm opposed to trusting only a signed git tag in your proposed > implementation, when it has been proven we can do much better. "Proven" to me implies that we have an implementation of tag2upload that has better security properties. I don't think this is true? If it is, I'd love to look at it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
