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:
>> 
>>>>> 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.
>> 
>> Yup.  If you ran a deblob-check in verify mode on the resulting
>> tarballs, you'd see how error-prone this is.  You'd at least stop
>> non-Free code from silently sneaking in and finding its way into running
>> on users' machines.  That's the *least* someone who runs the
>> deblob-scripts on their own should do to smoke-test the result WRT
>> *known* freedom issues.

> What is this "verify mode" that you're referring to, and where is it
> documented?

I'm talking about the --list-blobs (default) option of deblob-check,
that tests whether an input file (source file, patch file, or tarball)
contains any suspicious patterns.  Running deblob-check with --help
prints a significant amount of documentation, though it is mostly aimed
at the internal purposes that the scripts serve.

The cleaning up scripts are not really meant to be blindly used by third
parties to clean up anything but releases they're associated with;
they're provided for documentation and transparency purposes, but
they're not even something whose existence you should count on.  E.g.,
once we realize the long-term vision of having a git repo with the
entire history, manually cleaned-up, there won't be a script to clean
things up any more, though there will surely still be something to help
us identify anything that needs cleaning up.

> The word "verify" does not occur in either of the deblob
> scripts that I know about

That's what the 'check' in deblob-check stands for.  Originally, it
would only scan for blobs.  Later on, it was extended with other actions
for use in cleaning up.

> I don't see anything like a verification mode mentioned
> in the options documented at the top of those two scripts.

Indeed, deblob-<VERSION>, which is what you use, and deblob-check, as
used by it, do not perform any verification whatsoever.  They're not
meant to.  They automate and document what we intend to clean up.  The
verifications are steps we take once we have a candidate release, that
well us whether or not it's fit for release.  If it isn't, we adjust the
scripts and start over.

You'd have to run deblob-check linux-libre-<VERSION>-guix.tar on the
cleaned up tarball to check that none of the suspicious patterns known
by deblob-check have survived in the resulting tarball.  It would have
caught the errors that Vagrant hit the other day, and it would have
reported the deblobbing errors you'd have got this week had you not
waited for the updated scripts.

Running this script in -B or -C modes is part of our development process
for new releases, and it is also one of our safety nets to stop us from
releasing non-Free Software: we run it for every release before putting
it out.

> For the record, it was not my intent to skip any automated checking
> provided by these scripts.

I understand it was not your intent, but using the scripts in
environments it wasn't tested, with upstream releases or commits it
wasn't meant for, the expectation that it will do the job you wish
without any of the verification steps we perform is misplaced.


> If we're running the scripts in a suboptimal
> way, please tell me a better way.

> FYI, right now we're simply running the main 'deblob-<VERSION>' script
> with no arguments in the unpacked Linux source directory, with the
> corresponding 'deblob-check' script in $PATH and $PYTHON pointing to
> python 2.x.  If 'deblob-<VERSION>' exits abnormally or with a non-zero
> result, the Guix build process fails.

> Last I checked, 'deblob-check' was certainly being run by
> 'deblob-<VERSION>' as a subprocess, because I had to make several
> substitutions of hard-coded paths before it would work in Guix
> (e.g. /bin/sed and /usr/bin/python).

The expected use of the scripts, for people who wish to verify that our
releases have been cleaned up as specified in the scripts, is to do just
what you do, and then compare the resulting source tree with that of our
release.  If they match, you know we haven't sneaked in any unintended
changes.  If they don't, something went wrong on either end.

Given our amount of experience and automation in the release and
verification processes, that scan the resulting source tree and also
compare the changes with those made by an earlier known good recent
release, a platform-specific bug in the underlying tools, an unexpected
change to regexp engines (as in some recent version of python3), the use
of mismatched scripts are more likely sources of differences than our
failing to notice an unexpected change on our ends.


Now, if you wanted to use the scripts for purposes other than
verification, e.g., to clean up releases before we check them, or even
after we put them out but without any attempt to verify that the result
you get is indeed what we put out, you should take responsibility for
verifying the releases at least as much as we do, otherwise any freedom
issues arising from your not catching a problem we would have caught
would unfairly reflect negatively on our project.

-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer