On Aug 15, 2020, Mark H Weaver <m...@netris.org> wrote: > Alexandre Oliva <lxol...@fsfla.org> wrote: >> On Aug 12, 2020, Mark H Weaver <m...@netris.org> wrote:
>>> I also consider it unwise for all of us, as a matter of habit or policy, >>> to trust the integrity of the computer systems used by the Linux-libre >>> project to perform the deblobbing. >> >> I welcome double-checking of our cleaning up at all levels, but why are >> you setting a higher trust standard for us than for a project known to >> be at odds with our shared goals, such as Linux? > I don't understand how you reached the conclusion that I'm setting a > higher trust standard for Linux-libre than for Linux. You blindly trust Linux release tags, but not ours. OTOH, you're right that it's not a strictly higher standard. You also trust our cleanup scripts, even when we tell you they're not fit for the use cases you put them through. > The principle I'm following here is simply to avoid relying on the > integrity of any system if I can easily avoid it. You could avoid relying on the integrity of Linux release tags, and trust ours instead. That's what tells me you don't trust Linux-libre as much as you do Linux. You could use our tags, at the very least to check that you got something sensible out of your own deblobbing run, but you don't even look at them. You're not checking anything, so what you put builders through is at best busy, redundant work, and at worst, a waste of cpu cycles that doesn't even get them what they hope for. > However, I reject the argument that because we must > trust X and Y, we might as well trust Z as well. That doesn't follow indeed. What I'm saying was that, instead of trusting both X and Y, you might trust just X instead, while you insisted on trusting mostly just Y instead (but also X and a bunch of other tools used underneath). >> But the point stands that, for someone who'd rather trust no one, you're >> blindly trusting both Linux and Linux-libre. The former when it comes >> to base releases you don't check; the latter when it comes to scripts >> whose results you hardly even look at. Why not reduce your trust base >> to just Linux-libre, > That's not possible. Clearly, you do not have the capacity to audit all > of the code that Linux produces. Therefore, by trusting Linux-libre, we > must implicitly also trust the Linux project. That much we cannot > avoid. We also cannot avoid trusting your deblob scripts. True, we don't even attempt to audit Linux sources in this sense. This seems to imply that taking our cleaned-up sources, and taking Linux' sources and cleaning them up, carries exactly the same amount of trust on each project involved. And yet you prefer to trust the one that sneaks non-FSDG bits in every now and again, instead of the one that hunts them down and removes them. > However, we *can* easily avoid trusting the integrity of the systems > that you use to run the deblob scripts. You *could* avoid that, and also some blind trust on the underlying tools and systems used for cleaning up by us and by you, by at least *comparing* the cleaned-up tree you get with the one we provide. But that's not what you do. You distrust us enough to shed doubts on our processes, but you (and guix builders, trusting you) trust us enough to run our scripts for purposes they aren't fit, and trust a very complex and fragile combination of tools and systems to carry out its difficult job without giving their output a second look. > In fact, I strongly support reducing Guix's reliance on pre-generated > outputs produced by *any* project. I'm not singling out the Linux-libre > project here. You really are. You take most other projects' releases without anything even close to the amount of scrutiny and disregard that you place on the results of our release engineering processes and resulting release tarballs and tags. You might not think so if you consider the deblobbing scripts we publish for transparency and verification as our releases, but since they (very) occasionally remain unchanged even when new changes need to be made (*), say because they by chance already contain the code that makes the newly-needed changes, that supposed equivalence is a mistake. (*) just as I write this, I manually check 5.8.3-gnu and find a fresh example of this, also applicable to 5.7.17-gnu and 5.4.60-gnu. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer