Re: Linux-libre 5.8 and beyond

[Alexandre Oliva]

On Aug 15, 2020, Mark H Weaver <mhw@netris.org> wrote:

> Alexandre Oliva <lxoliva@fsfla.org> wrote:
>> On Aug 12, 2020, Mark H Weaver <mhw@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