Re: Linux-libre 5.8 and beyond

[Mark H Weaver]

Hi Jason,

I didn't see your email until just now.  I read this list only
sporadically, so it's best to keep me in the CC list for messages that
you'd like me to see, or that are responses to me.

Mark H Weaver <mhw@netris.org> wrote:
>> the linux-libre project periodically deletes most of its older
>> tarballs, even if there are no accidents.

Jason Self <jason@bluehome.net> responded:
> Just FYI that git://linux-libre.fsfla.org/releases.git was created
> mainly to solve that problem. Versions are now pretty much permanent.

That's helpful, thanks.  I didn't know about this.  Out of curiosity, is
this git repository advertised anywhere?  I wasn't able to easily find
it on <https://www.fsfla.org/ikiwiki/selibre/linux-libre/>, but I didn't
look carefully, perhaps I missed it.

One question: Would it solve the problem that I mentioned in my earlier
email, namely the problem of how to determine which precise commit
introduced a regression between two stable kernel releases?  If not, I
think that justifies the machinery that Guix includes to do the
deblobbing itself.

>> It may be useful for users with newer hardware devices, which are
>> not yet well supported by the latest stable release, to use an
>> arbitrary commit from either Linus' mainline git repository or some
>> other subsystem tree.
>
> The cleaning up scripts are version-specific and won't work on an
> "arbitrary commit from Linus's mainline git repository" (i.e., someone
> wanting to get today's most recent commit going into 5.9.) The scripts
> would fall over and die in such a scenario,

Okay, perhaps this was wishful thinking on my part.  I had hoped that
the deblob scripts would typically mostly work, even if they weren't
able to do a comprehensive cleaning.  I would oppose adding such a
partly-cleaned kernel to Guix itself, but I wanted to enable users who
need to use some other branch of Linux on their own systems to make a
best-effort cleaning.

>> It allows us to update to a new point version (which usually
>> includes security fixes) more quickly, before the linux-libre
>> project reacts.
>
> Any attempt outrun the Linux-libre project and get updates out sooner
> is unwise. While major new kernel releases will definitely require
> updates to the cleanup scripts, even minor patched versions
> occasionally require changes too. Updating to a new version prior to
> the Linux-libre project having had time to review that new version and
> determine if any updates are needed to the scripts risks introducing
> freedom problems in the corresponding Guix version.

In my experience, the deblob scripts are very rarely changed after the
first few point releases of a stable release series.  I know this
because I always check for updates to the deblob scripts whenever I
update linux-libre in Guix.  In practice, the deblob scripts used by
Guix are never more than 1 or 2 micro versions behind the version of
Linux they are applied to.

> The moment that the Linux-libre project determines that scripts are
> suitable is the moment that the new cleaned-up release is ready to
> publish in git and the appropriate tags will then appear in git. The
> compressed tarballs come some time later.

I prefer to avoid unnecessary delays when applying micro kernel updates,
because I assume that many of the fixes are potentially security fixes
(although they are rarely marked as such because upstream does not
attempt to determine the security relevance of most fixes, which is
reasonable).

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.  It's not that I doubt the competence
of those people who maintain or administer those systems; it's that I
think it's unwise to trust *any* computer system that we can easily
avoid trusting.  Personally, I don't consider any modern civilian
computer system to be trustworthy, and especially not one that paints a
target on its back by being a potential vector for compromising the
machines of large numbers of users.

Enabling users to run the Linux-libre deblob scripts on their own
computers (as I do; I *never* use substitutes) enables them to remove
one computer system from the set of systems that they must trust.  I
think that's a good thing.

     Regards,
       Mark