Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Alexandre Oliva]

On Aug  6, 2017, Henry Jensen  wrote:

> RMS mentions a change "to obfuscate the names of the firmware files"
> instead of failing.

Yeah, he was referring to the "Request for Comments" section at
http://www.fsfla.org/anuncio/2010-03-Linux-2.6.33-libre

> Last time I checked, the situation hasn't changed,

It has changed a lot, actually, but not exactly in a favorable way.

Obfuscating blob names in sources would just create alternate names for
blobs, solving nothing, while turning sources into non-sources under the
GPL: they would no longer be the most convenient way to make changes to
the software.  In order to distribute them, or binaries compiled out of
them, we'd have to distribute the corresponding sources along with them.
Oops ;-)

Also, Linux changed so as to pretty much deprecate the userland hotplug
script used to load firmware.  Its firmware loading machinery can now
look directly in the filesystem, within /lib/firmware or elsewhere.  In
this setting, the idea of one-way-hashing the blob name before passing
it on to the userland hotplug script thus became moot.

Another concern is whether looking blobs up /lib/firmware when it's NFS-
or fuse-mounted is enough of a request to enable it to be construed as
user inducement.  Probably not in FSDG desktop-targeted distros, but GNU
Linux-libre is designed to be installable even in freedom-hostile
distros, so the requirements are more stringent.

We have considered, for example, the possibility of a distro's
fuse-mounting /lib/firmware so that a userland program monitors the
requests and offers to install requested firmware, just the kind of
scenario that motivated us to want to one-way-hash the requests to the
hotplug script.

In an attempt to work around this kind of attack, we considered even
requiring userland to enumerate firmware filenames to the kernel, and
arranging for the kernel to only issue requests to filenames listed in
the enumeration.  The fuse-mounted /lib/firmware could, however, list
all blobs available for on-demand installation, defeating even the
pre-enumeration.

At that point, we decided the problem was not fixable, and that, because
of the design of the firmware-loading machinery, we'd have to keep on
disabling the loading of blobs altogether in order to be on the safe
side WRT inducing their installation.

However, we also agreed that desktop-focused distros, that didn't
attempt to induce and facilitate the installation of blobs by the
above-described means, could very well relax these stringent
requirements, and distribute versions of Linux that didn't completely
disable blob-loading, and just refrained from mentioning the blob names
in logged errors.  I'm not sure the Debian kernel gets that far, I'm
afraid.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Henry Jensen]

Am 7. August 2017 02:45:35 MESZ schrieb bill-auger 

>regarding the debianized kernel itself - other users on this list are
>far more knowledgeable on it's inner workings than i, so i wont add
>much
>about that - except to say that if the only problem is some log files
>that very few people will ever read then surely there must be a
>workarounds ranging from simple to not-very-complicated - e.g. an init
>script or cron task that scrubs the logs of naughty words, or patches
>taken from linux-libre to supress them entirely

Writing file names of proprietary software in log files is not ideal but it is 
far more preferable than failing to load the firmware file. There was a 
suggestion on this list, to print a warning in the log files: 

http://lists.nongnu.org/archive/html/gnu-linux-libre/2010-12/msg00062.html

I think this would be the easiest and most practicable way. I will try to 
implement it at my next kernel build. 

Greetings,

Henry

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Henry Jensen]

Am 7. August 2017 03:40:08 MESZ schrieb Jason Self :
>Henry Jensen  wrote ..
>> This was an error by me, I did not update the symlink to the source,
>> which is located at 
>> https://connochaetos.org/slack-n-free/slack-n-free-14.2/d/. This is
>> fixed now.
>
>Thank you, although even with this change I still cannot account for
>all of the source code for all of the binary packages available.
>coreutils for example and many others.


ConnochaetOS consists of 3 repos: the liberated slackware repo, the liberated 
salix repo and the slack-n-free repo. The latter contains only additional 
packages, e.g. replacements for undesired  software in the upstream repos with 
the sources at https://connochaetos.org/slack-n-free/source/src/. Depending 
from which repo a program originates you find the corresponding sources at the 
source directory of this repo. Coreutils originates from the liberated 
slackware repo, so the sources are at 
https://connochaetos.org/slack-n-free/salix/i486/slackware-14.2/source/a/coreutils/

Greetings,

Henry

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Henry Jensen  wrote ..
> This was an error by me, I did not update the symlink to the source,
> which is located at 
> https://connochaetos.org/slack-n-free/slack-n-free-14.2/d/. This is
> fixed now.

Thank you, although even with this change I still cannot account for
all of the source code for all of the binary packages available.
coreutils for example and many others.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Henry Jensen  wrote ..
 
> Yes, thank you for linking to the messages. RMS mentions a change 
> "to obfuscate the names of the firmware files" instead of failing. 

That was not the primary reason for linking to that message. Pay
attention to his very first statement:

> It sounds like the new Debian version of Linux will recommend
> specific nonfree firmware programs, which is undesirable.

The thing he's referring to in that statement is the logging. Feel
free to write him if you don't believe it.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Ivan Zaigralin]

On Monday, August 07, 2017 00:10:39 Henry Jensen wrote:
> Am Sun, 06 Aug 2017 14:27:01 -0700 (PDT)
> > But if your decision is to continue to push back on this and leave the
> > request_firmware calls in place and unmodified, then I think my review
> > of ConnochaetOS is over.
> 
> That is, of course, for you to decide. However, I didn't found any
> official statement (meaning a statement at fsf.org or gnu.org), that
> writing names of proprietary firmware files in a log file are rendering
> a distro not recommendable or a software as not usable in a fully free
> distro. Some random messages on this list are not official
> statements.

Well said. I think, if ConnOS makes the leap towards official FSDG 
certification, it will be worthwhile to explain the difference between Debian 
kernel packages and the ConnOS kernel package.

Just because the kernel is capable of loading a firmware file which bears the 
symbolic name of an extant nonfree firmware blob, it's hard to see how FSDG is 
violated. The problem with Debian is that their "free" installer will 
literally prompt for a USB with nonfree drivers at installation time if one of 
these turd-chips is detected. From what I learned about ConnOS, its kernel 
package does no such thing. In the absence of the (nonfree) firmware file it 
simply moves on with a terse message in the log, stating that file was not 
found.

I personally think the difference is huge, even though the kernel is deblobbed 
in a similar way. If my understanding is correct, then I don't see how one can 
argue that ConnOS guides users toward nonfree firmware.

I was also amused to find out that Linux-libre decided to ignore RMS' 
suggestion and blacklist the blobs rather than obfuscate the calls :) It 
certainly helps to explain ConnOS' stance on why the Libre-linux approach is 
not that great either. I personally think that either approach is perfectly 
sufficient, and neither is heavy-handed, but I can also totally appreciate 
when a maintainer opts towards the Debian way for technical reasons. 

And here's another thought, besides the point raised above, but still 
pertinent: who in a 1000 years would use ConnOS and its deblobbed kernel in 
conjunction with nonfree firmware? Crazy people? ConnOS is the poor robot's 
Slackware, no offense meant. It is a fact of life that Slackware to this day 
has no close-source components besides the kernel, so anyone dropping a 
nonfree kernel into ConnOS (or FXP/Freenix, same deal) is not thinking 
straight: they are essentially getting the stock Slackware back, after jumping 
through a series of flaming hoops. Sure, there are things like xv and xgames 
and fractint in Slackware, but they and all the other nonfree packages are 
museum pieces at this point in history. When it comes to users' freedom, they 
make virtually no difference in practical terms. OK, so there's also mozilla, 
but again, free-e-fied ice* packages are available from various binary repos, 
so the objections about the way the kernel is deblobbed are missing the point.

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[KRT Listmaster]

On 08/06/2017 10:37 AM, Jason Self wrote:
> Henry Jensen  wrote ..
> 
>> The link to the freeslack project shouldn't be a problem, since
>> the page at https://www.gnu.org/distros/common-distros.html links
>> to the very same project.
> 
> There is no reference to FreeSlack on that page, only Slackware.
> 
> But even if we consider Slackware, what is being said also be
> considered: That page is discussing why Slackware is not acceptable
> for adding as an FSF-endorsed distro.
> 
> In comparison, the text I'm referring to is an out-and-out referral to
> go *use* it if someone wants a 64-bit version: "If you are looking for
> a libre Slackware x86_64 variant you are welcome to use the x86_64
> slack-n-free repo and have a look at the FreeSlack project."
> 
> In one case, the statement (on gnu.org) is about why Slackware is not
> acceptable. The other is a statement to go use it if they want 64-bit.
> These are not the same. An FSF-endorsed distro shouldn't steer people
> to using ones that are not.

This is a misunderstanding, I think.  There is an indirect reference
(via a weblink) at the end of the Slackware section on the gnu.org when
it says

"There is an unofficial list of nonfree software in Slackware.",

the words "unofficial list" link to

http://freeslack.net/

which has evolved beyond a mere list and is now a fully installable
distro.  So, when ConnochaetOS suggests using "it", they mean FreeSlack,
which has every intention of being a fully-libre distro with
downloadable and installable iso files while adhering to the GNU-FSDG [1].

The link to the same project website (which cross-suggests ConnochaetOS
for 32-bit users) is just worded poorly on the gnu.org page.  Neither is
suggesting the use of Slackware proper.  However, both links ARE
referring to a fully-libre software project, regardless of current
FSF-endosement status.

- KRT

[1] https://freeslack.net/dokuwiki/doku.php?id=project_goals

-- 
This email account is used for list management only.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

The FSF can, of course, set whatever criteria/conditions they want in
order to put their name behind something.

While I don't pretend to speak for the FSF the things I point out are
things that, based on past experience, are problematic points to
address if the end goal is indeed to get the FSF to put their name
behind ConnochaetOS. (As one example, the consensus on this mailing
list for years has been that the notion that the Linux kernel logging
firmware names when they're missing is not desirable. I've even
provided references to that effect. The list archives may very well
provide other such references.)

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Ivan Zaigralin]

On Sunday, August 06, 2017 09:37:16 Jason Self wrote:
> Henry Jensen  wrote ..
> 
> > The link to the freeslack project shouldn't be a problem, since
> > the page at https://www.gnu.org/distros/common-distros.html links
> > to the very same project.
> 
> There is no reference to FreeSlack on that page, only Slackware.

You do not consider a web link a reference? Both the cited FSF page and the 
FSFLA Linux-libre page link to the FreeSlack project.

> But even if we consider Slackware, what is being said also be
> considered: That page is discussing why Slackware is not acceptable
> for adding as an FSF-endorsed distro.
> 
> In comparison, the text I'm referring to is an out-and-out referral to
> go *use* it if someone wants a 64-bit version: "If you are looking for
> a libre Slackware x86_64 variant you are welcome to use the x86_64
> slack-n-free repo and have a look at the FreeSlack project."

Please do not confuse FreeSlack with Slackware, the names are not THAT 
similar, and if you read the statement on the front wiki page, you will see 
FreeSlack is a documentation project which is NOT affiliated with Slackware 
project, and its distribution arm is free software. The distribution name may 
be A BIT confusing, which is why we are in the process of changing it to FXP 
or Freenix or something else, which is up to FSF at this point. We applied for 
FSDG certification in March 2016, and so far we haven't heard any suggestions 
from the FSF review team besides changing the name collision, which we agreed 
to do. Since then several months have passed, and we have not heard any 
comment about either "FXP" or "Freenix", leaving us in a kind of a nameless 
limbo. So at present, we think, we have zero outstanding issues with respect 
to FSDG.

> I imagine that FSF-endorsed distros should probably not steer people
> to others that are not?

That would be a gross misrepresentation of the FSDG guidelines. Free 
distributions should not stir people towards non-free software, period. ConnOS 
is free software, which is why here at FreeSlack we think it's OK to mention 
them as an option for x32 arch. The FreeSlack's distribution, FXP, is also 
free software, Linux-libre-powered and without the Debian kernel controversy, 
so of course there are no issues about ConnOS linking to FreeSlack either. 
None of that has any bearing on FSDG compliance.

I would agree that IF a Debian-style kernel SUGGESTS and STIRS users towards 
firmaware blobs, then the kernel should fail the FSDG. I am not in the 
position to comment on the specific kernel used in ConnOS, since I never 
studied that portion.

I am also personally of the opinion that it's OK for an FSDG-compliant 
distribution to suggest an option which is free, although not necessarily 
FSDG-compliant. There's nothing wrong, IMHO, about informing users about 
Debian-style free kernels as viable options as long as the users are warned 
about the blobs. I know not everyone will agree, since this is kind of a gray 
area, but I think you can all understand my reasoning: at some point the user 
should admit some responsibility.

Like RMS said, of course free software will allow you to install and run 
nonfree software, there's no cure for that, and it's not even a tragedy of any 
sort. But we don't declare web browsers nonfree, even though most of the big 
ones, like konqueror, are designed to drop the user into the javascript trap 
by default. We just admit that users should know better than to enable 
javascript on pages they don't trust to serve 100% free software.

There's only so much hand-holding we can do as distro-maintainers, and 
preventing user from exploring viable 100% free-software options such as the 
libre channel of the Debian repository is simply not our job. There's no 
contradiction here, as far as I can see: FSF should not endorse Debian-style 
shenanigans if it doesn't want to, but FSF has no business telling other 
projects, even the one they endorse, to stop mentioning free software 
compilations which themselves fell short of FSDG.







signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jean Louis]

On Sun, Aug 06, 2017 at 09:37:16AM -0700, Jason Self wrote:
> In one case, the statement (on gnu.org) is about why Slackware is not
> acceptable. The other is a statement to go use it if they want 64-bit.
> These are not the same. An FSF-endorsed distro shouldn't steer people
> to using ones that are not.

I agree so much on that one.

Even I am aware that many people are not aware of
software freedoms and what it means for future.

It requires teaching people in a mild manner with
care for understanding to take place.

> It's not necessary to tell people how to get
> them in order for it to count as an
> inducement. In this case people's log files get
> spammed with "file not found" error messages. If
> memory serves this matter has also come up with
> RMS before too, and he's on board with the name
> scrubbing. All other endorsed distros use
> Linux-libre. Why should ConnochaetOS receive a
> special exemption?

I do not think that ConnochaetOS shall use
Linux-libre, as long as they use fully free Linux
kernel from any party.

I also do not think that a full free GNU
distribution need to use Linux kernel at all, it
just happens at this point that they are using it,
but in future there can as well exist GNU based on
Minix or Hurd or some type of BSD kernels or
others. 

There are obviously very good points in
ConnochaetOS to be included on the list, I wish to
see it.

> - The installer advertises itself as "ConnochaetOS Linux"
> Based on the entry for "Linux system" in the link to Words To Avoid in
> the "Please Avoid Repeating Propaganda and Confusion" part of the GNU
> FSDG this should be changed to GNU/Linux or the Linux reference
> eliminated.

I agree on that one, that is wrong. It refers to
Linux as operating system in that context which is
just contributing to further confusion.

I hope to see more free distributions being
endorsed.

Jean

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Ah, I managed to find the ones I was thinking of:

http://lists.nongnu.org/archive/html/gnu-linux-libre/2010-12/msg00033.html

http://lists.nongnu.org/archive/html/gnu-linux-libre/2010-12/msg00032.html

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Henry Jensen  wrote ..

> The link to the freeslack project shouldn't be a problem, since
> the page at https://www.gnu.org/distros/common-distros.html links
> to the very same project.

There is no reference to FreeSlack on that page, only Slackware.

But even if we consider Slackware, what is being said also be
considered: That page is discussing why Slackware is not acceptable
for adding as an FSF-endorsed distro.

In comparison, the text I'm referring to is an out-and-out referral to
go *use* it if someone wants a 64-bit version: "If you are looking for
a libre Slackware x86_64 variant you are welcome to use the x86_64
slack-n-free repo and have a look at the FreeSlack project."

In one case, the statement (on gnu.org) is about why Slackware is not
acceptable. The other is a statement to go use it if they want 64-bit.
These are not the same. An FSF-endorsed distro shouldn't steer people
to using ones that are not.

> I have a diferent view. The statement from the FSF at [1] can be
> interpreted in the way, that the de-blobbed Debian Linux kernel is
> regarded as entirely free software.

That deblobbed kernel is indeed free software; this discussion is
solely about the "inducement" part.

> Our installer doesn't do such things.

I'm not discussing the installer.

> Yes, there may be occurrences of  names of proprietary firmware 
> blobs in log files. But they are not recommendations, simply names.
> We do not steer people to this proprietary files, since we are not 
> telling people how to get them.

It's not necessary to tell people how to get them in order for it to
count as an inducement. In this case people's log files get spammed
with "file not found" error messages. If memory serves this matter has
also come up with RMS before too, and he's on board with the name
scrubbing. All other endorsed distros use Linux-libre. Why should
ConnochaetOS receive a special exemption?

I've installed ConnochaetOS in a virtual machine and have also made
these observations:

- I like that the browser has been modified to send people to the FSF
Directory for add-ons. That avoids the matter of steering people to
non-free add-ons.

- I like that the browser sends people to the non-JavaScript version
of DuckDuckGo, eliminating the JavaScript Trap.

- The installer advertises itself as "ConnochaetOS Linux"
Based on the entry for "Linux system" in the link to Words To Avoid in
the "Please Avoid Repeating Propaganda and Confusion" part of the GNU
FSDG this should be changed to GNU/Linux or the Linux reference
eliminated.

- Some of the documentation contains no copyright or licensing
information. An example:
https://connochaetos.org/slack-n-free/salix/i486/slackware-14.2/Slackware-HOWTO
but this also applies to the speak install and speakup docs files.

According to the FSDG, "all the documentation in a free system
distribution must be released under an appropriate free license." It's
possible that this is already supposed to be free, but just not stated.

The Slackware Howto is also talking of "Slackware Linux" and "the
Linux operating system", which continues the notion of the "Linux
system" mentioned earlier. Further, I'm not sure that sending people
to the Slackware website for further information is the best approach
that an FSF-endorsed distro should take (The Slackware documentation
wiki has a lot of information...)

These may be fixable, depending on the license and if modifications
are allowed.

I've also not been able to locate the source code for the kernel.
https://connochaetos.org/slack-n-free/source/src/linux/ doesn't have
it even though other directories in the parent appear to have source code.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Henry Jensen]

Hi Jason,

Am Sat, 05 Aug 2017 22:06:59 -0700 (PDT)
schrieb "Jason Self" :

> J.B. Nicholson wrote:
> 
> > I see on https://connochaetos.org/wiki/ that ConnochaetOS "is
> > available for x86 (32 bit) only" and directs users looking for an
> > x86_64 libre Slackware GNU/Linux distro elsewhere.  
> 
> That is probably a valid point. I imagine that FSF-endorsed distros  
> should probably not steer people to others that are not?

The link to the freeslack project shouldn't be a problem, since
the page at https://www.gnu.org/distros/common-distros.html links
to the very same project.


> In addition, I think that the documentation at [0] should probably be
> updated to steer people to the Linux-libre deblob scripts (or their
> already deblobbed tarballs?) The fundamental problem is that the
> method used by the Debian Project leaves the request_firmware calls in
> place, resulting in people's system logs being spammed about how the
> proprietary software is missing from their system. Linux-libre's
> deblob scripts handle this by removing code that induces users to
> install non-Free Software.

I have a diferent view. The statement from the FSF at [1] can be
interpreted in the way, that the de-blobbed Debian Linux kernel is
regarded as entirely free software.

The statement at [2] says it is a problem, that 

"the installer in some cases recommends these nonfree firmware files
for the peripherals on the machine." 

Our installer doesn't do such things. Yes, there may be occurrences of
names of proprietary firmware blobs in log files. But they are not
recommendations, simply names. We do not steer people to this
proprietary files, since we are not telling people how to get them.

I don't see that the pure reference to the name of a proprietary
software would be a recommendation. There are many other parts, in
other FSF endorsed distros as well, where names of non-free software
do occur. E.g. many packages names of Trisquel have the name
"ubuntu" in it. If I would do a full text search on any endorsed system
I am sure, that there would be many occurrences of names of proprietary
software.


Greetings,

Henry



[1]https://www.fsf.org/news/debian-squeeze-makes-key-progress-toward-being-a-fully-free-distribution
[2]https://www.gnu.org/distros/common-distros.en.html