Philipp Kern <pk...@debian.org> writes: > On 11/21/24 9:51 AM, Simon Josefsson wrote: >> I support going even further: I think the Debian build infrastructure >> should over time be moved over to Salsa pipelines. GitLab pipelines >> offer a lot of transparency, security and reproducability benefits >> compared to the current Debian buildds which in my perception operate >> under a "trust us we know what we are doing but we can't be bothered to >> be transparent about it" policy that doesn't inspire confidence in me. > > Generally everything is in publicly available git repositories, if you > know where to look (somewhere distributed between wanna-build, buildd, > pybuildd, and dsa-puppet). The setup of the coordinator in particular > suffers from only having a single installation (not even a staging/test > one), though. > > I agree in principle in that a lot of trust needs to be extended to the > management and operation here - and we could do much better. I'm not > sure if pipelines are any better if the runner could equally tamper with > the builds. But everything is in git somewhere.
I was thinking more about operations than source code availability. Compare the effort that goes into the visibility and transparency of things built through a GitLab pipelines. Who authorized what, and how things were triggered, is chained back to users, in an authenticated fashion that is simple to follow on a web page, with admin pages for the credentials involved. Compare that with Debian. How can I find out who triggered a binNMU to rebuild a package, for example? Where is the list of credentials allowed to upload into the archive? How are they managed? Another example is SSH-signatures and Sigstore/Sigsum transparency chain mechanisms to provide stronger security properties than PGP signatures. From what I can tell, the apt team wish to prevent improvements in this area, preventing us to protect users from attackers with that ability. I disagree with the notion that everything is in git, Debian gave up on that as a useful argument with the non-free firmware vote. We don't have access to all source code. It could contain instructions that may be triggered to alter the operations of the buildd infrastructure. Other projects like Guix have mechanism to test and challenge the integrity of offical builds to protect against these attacks. (No, Debian's reproducible build doesn't do this.) Don't get me wrong: I do appreciate the outcome from the current Debian build machinery. And I do see a lot of problems in the GitLab/GitHub world. They are a huge complex beast with many poor security practices (oauth vs pgp, for example) and an unhealthy reliance on the web browser compared to CLI tools. But if I look from the outside and try to judge who is even attempting to solve problems and build the state of the art secure infrastructure to address supply chain software build attacks, my perception is that the Debian/Ubuntu setup was overtaken by the GitLab/GitHub web kids five years ago. I wish it weren't so, and I grow up in the old era and prefer it, but let's not be blind to how things are due to nostalgia. I believe that Otto's lets-standardize-on-salsa effort is fundamentally a good thing. Let's help him flesh out the details. /Simon
signature.asc
Description: PGP signature
