hey, last week I've attended the Reproducible Builds World Summit #3. It was even better — for me — than last year, because this time I knew quite a bit more what I was talking about: last year we had not started our own work on this topic, so all the experience I had was about making Debian packages build reproducibly.
Here are some very subjective highlights. Reporting back & sharing knowledge ================================== I've facilitated a session about making system images reproducible. It was very popular: about 8-10 people attended, mostly Qubes OS and Debian folks. I've mostly pointed out the main known issues and solutions based on our experience. Personally I've not learned much, except that there's a tool to create reproducible ext4 FS images, which can be interesting for our VM images (on the Vagrant and cloud/infrastructure side) and for the upcoming research process about revamping our install/upgrade, on-disk format and distributed images format. Attendees were pretty excited about the fact it now seems doable to build reproducible system images (disclaimer: we're *not* the first ones, another Debian Live system did it before). I've also run a 1-to-1 skill sharing session about our APT snapshots system, attended by a Qubes OS developer. We came up with an idea that could allow us to keep the signatures from the Debian archive, even in partial "tagged" snapshots, instead of shipping our own. It's not trivial to implement but it would bring quite some value to our reproducibility feature. I'll keep this in mind for [stage 2]. [stage 2] https://labs.riseup.net/code/issues/14455 Documentation ============= With Ulrike and lynxis we've de-Tails-ified the [report] I've sent a few weeks ago about how we made our ISO image build reproducibly. It's now [live] on the RB website. The goal is to gather and share knowledge with anyone else who want to make their own system images reproducible. As you know, it is super important to me that we work in a way that's well connected with the broader ecosystem and communities around us, and that we share whatever knowledge we learn, whatever tools we create, in the process. I hope this sets a good example of how this should be done (no, humility is not my strongest skill, that's a known issue :) [report] https://lists.reproducible-builds.org/pipermail/rb-general/2017-October/000656.html [live] https://reproducible-builds.org/docs/system-images/ What can we call "reproducible"? ================================ This was the most important and challenging task I brought with me to this event. What we can legitimately call "reproducible" is a somewhat touchy topic in a community whose name includes "reproducible"; makes sense, doesn't it, uh? The timing was perfect, as our plan is to start boasting publicly about "Tails is reproducible" in 6 days. So I initiated a discussion on this topic during the session about system images, and followed-up on it privately with a number of attendees in order to convince myself we had buy-in from this community. At first it was not obvious to me, and to a number of attendees, that assembling an image from a bunch of binary blobs satisfied the criteria we have for calling it reproducible. Then, while discussing this topic, we realized that: - The compilation process for some packages includes stuff that comes straight from binary artifacts shipped by other packages (build-dependencies); I don't recall what exact examples were provided about C programs, Ximin knows better and it's definitely outside of my comfort zone. - The official [definition] of "reproducible builds" that we created at the same event last year allows one to have build-dependencies. Arguably the packages we fetch from (our own snapshots of) the Debian archive are build-dependencies. So we're good… in principle. But how we shape our communication does matter: the limit between "we're good" and "we're diluting/corrupting the RB message" is thin and we're playing exactly around this limit. Let me clarify: even though in principle everyone agreed with this, there was a consensus that when calling such things reproducible, one must make it clear what's their input, source code and build-dependencies. In our case, we should make it clear that we are *not* building everything from source, and we're rather *assembling* an ISO image whose content comes at 99% from *binary* build-dependencies. [definition] https://reproducible-builds.org/docs/definition/ End-user policy =============== We had great discussions about how to convey the value of reproducible builds to end-users in a meaningful and actionable manner, e.g. "I want to install only reproducible packages". I'm too lazy to explain what we came of with now (notes were taken and there will be a global report from the event), but process-wise I was extremely happy and somewhat surprised: we quite easily managed to take a user-centric PoV, to avoid diving into implementation details when it didn't matter, to think in terms of value proposition, and to avoid pretending we're good at designing GUIs. We also managed to take exceptions into account (e.g. packages that are not reproducible yet, proprietary blobs actual users need to get their Wi-Fi working) which is often the hard part when designing such systems. My secret mission about this before going to this event was to ensure dkg (and not myself) would lead this effort. I'm glad I can say it worked :) Now, one person volunteered to implement one of the needed backend bits, but I don't think anyone formally committed to facilitate/lead the next steps of this process. It's no big deal IMO as we were aware these discussions were kinda premature. I'm confident what we produced will be a solid basis for whoever comes next, possibly at the next RB summit, and — who knows? — earlier. Interestingly, if/once this gets implemented, this will allow us (non-trivially again but still) to ensure the packages we install in our ISO are the same as the ones that N reproducers have built, which again would be good for our stage 2: even if our indices and signatures are different, at least we'll have a guarantee that the *contents* of these packages was not altered on our infrastructure, which is a pretty good start. Questions are welcome. cheers, -- intrigeri _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
