Philip Hands <p...@hands.com> writes: > Hi Simon, > > Simon Josefsson <si...@josefsson.org> writes: > >> While this may be fine to you it is not fine to me, and it is fine to >> disagree on that. > > If there were a method of building images that did not touch the > non-free components, I presume that would satisfy you.
That sounds good! > Let's say that we could make that image bit-for-bit reproducible with an > image that was produced by taking the normal with-nonfree-firmware > image, and filtering it somehow (e.g. overwriting the non-free bits with > zeros, say). > > Would you object if the normal way of generating the image was to apply > the filter, rather than build it in parallel? > > If that would be OK, then one could have something that applied the > filter to our normal images to provide people with the images you want, > while not require duplication of building and storage. > > People could always confirm that they were getting the same result as > building without the nonfree firmware by doing it themselves, and > checking things matched. > > Is that something that would work for you? This is better, assuming the "doing it themselves" property is actually confirmed. Your idea is really clever! My assumption all along has been that the presence of the non-free firmware in the build process "taint" the resulting image in a way that makes it impossible be able to 1) zero out the non-free firmware bits from the resulting image, and at the same time 2) be able to separately build a bit-by-bit identical image using only free software and that this image would become identical to the zeroed out image. But you made me realize this is not impossible at all, it is just a Small Matter Of Programming. You could turn this around: how about building the images without non-free software, and replace the zerod out bits with the non-free firmware on final preparation of the non-free images? Then your normal build process is not tainted by the presence of non-free software. I don't think the above fully resolve my concerns though. The mere presence of official documented hooks to load non-free software is problematic from a freedom perspective. They are the enabler of the slippery slope that leads to including non-free software by default. Meanwhile I looked into the debian-cd project to experiment with building images myself. Why aren't the images built in a Salsa pipeline? Yes I understand that 20 years ago the resources required to build the images were large. But today people build large projects in GitHub Actions. What artifact size are we talking about? Looking at the summary of official images at https://www.debian.org/CD/http-ftp/ it seems like around 50GB? What is the build time on a powerful machine? I would start to worry about the design feasability of running this in a pipeline when the total size of artifacts from a single build is larger than 4TB or if a single serialized job would have to run for more than a couple of days. I'm probably missing some combinatorical explosion of varaints that increase the total size, but there is also no requirement that all images are built like this. I would be satisfied if the "netinst" variant for all architectures could be reproduced from purely free software, in a Salsa pipeline, and that seems to be a 5-10GB artifact unless my math is off. I worry that the builds require other non-reproducible/free steps though. A signed boot shim where the private key is not replaceable by a user-controlled key is equally problematic as non-free firmware. Trisquel and Guix avoids these, and I recall seeing stuff like that in Debian -- https://tracker.debian.org/pkg/shim-signed -- but it is good to know that we have more things to work. /Simon
signature.asc
Description: PGP signature
