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] gnu.org "Free GNU/Linux distributions" list updates

[Alexandre Oliva]

On Aug  6, 2017, Jaromil  wrote:

> in case you follow up on BLAG's website restoration, please consider
> at Dyne.org we can also be hosting the BLAG website, which I remember
> to be simple enough and could be made static.

Thanks.  blagblagblag.org is still up; blag.fsf.org, that's down, was
much bulkier, in that it had the install isos and tree composes.

-- 
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] gnu.org "Free GNU/Linux distributions" list updates

[bill-auger]

not that anyone asked but jaromil may be pleased to hear that dynebolic
v1 was (i think) the 2nd distro i ever tried before i ever heard of GNU
or the FSF - liveCDs were quite "cutting-edge" then and it seemed like a
very easy way to try out this nerdy "linux" thing i had been hearing
about - i can say that the dynebolic website was my first introduction
to the free software "philosophy" (indeed that there was any
"philosophy" behind it at all) - most of what i had heard was only that
this "linux" system would allow you to customize any of it's programs if
you knew how to read code - i did not know how to program very well at
the time (some TI-BASIC - yay) but the idea of having such a modern
environment conducive to experimentation was very inviting; and i
figured that, because i am a curious fellow, i would eventually become a
competent programmer if i just started using it - then the more i
learned about programming: the more i learned about and appreciated the
GNU "philosophy" - whatever fwiw that's my lil story in a nutshell

Re: [GNU-linux-libre] gnu.org "Free GNU/Linux distributions" list updates

[bill-auger]

firstly, let me say that i am pleased that this thread has gotten so
much attention - judging only by the activity on the libreplanet wiki,
the amount of interest in this distro list was not apparent

frankly, i would like to address that and to continue the discussion of
transparency generally before it evaporates

i have been assuming that this mailing list was explicitly intended to
be the public forum (with official FSF participation) for discussion of
the distro evaluation process with the 'Incoming_Distros' wiki page[0]
and section 5 of the 'FreedSoftware' group page[1] as the public
reference for the official results; and that those wiki pages have
simply fallen into neglect over the years - on the other hand, it has
been suggested in this thread that the FSF prefers to be discreet as not
to embarrass distros during the evaluation; which would imply that there
was never intended to be any official source of information documenting
the review process - i do not intend to argue either point but they can
not both be the case; and it is not clear which one is the reality

if discretion is the policy then i would like to point at the list of
"common" distros that "We Don't Endorse"[2] and the list of individual
software projects that are not FSDG-free on the libreplanet wiki[3] - if
the FSF does not have a discretion problem with those well-known
projects then i dont see why "un-common" distros would be exempt from
the same treatment (at least after the evaluation is completed) - in the
end, if a distro is endorsed, it will eventually appear on the "Free
GNU/Linux distributions" page; but otherwise, how would anyone know
whether or not it was ever considered or what the problems were that
prevented it from being endorsed? - it is quite often that someone asks
in the #fsf channel "why is FooDistro not on the list?" - the usual
answer is like: "i dont know - maybe they didnt ask - maybe it failed
(some?) criteria"

ideally - it would be very nice to make the
'Free_System_Distribution_Checklist'[4] more complete and rigorous so
that the criteria are not as subject to interpretation as they seem to
be now; and to keep a public table itemizing the "pass/fail" status of
each criteria for each distro (even if some criteria were still
inherently fuzzy - it would still be more useful than no information at
all) - even if, in the end, a distro did not desire to be (or had not
the resources to become) in fully accordance with the FSDG; still,
anyone reading that table could estimate how much work it would be to
fork or to make their copy of it FSDG-free - just an idea; but as of
now, users have no guide for choosing a distro other than: "yes - it is
endorsed" vs. "i dont know - you figure it out" - even if discretely
omitting explicit details such as the table suggested above, it would
still be helpful (and quite feasible) to distinguish the following four
cases which are well-defined and exhaustive:

* it is endorsed
* it is under consideration
* it was found to be not fully in accordance with the FSDG
* they haven't asked yet (implicit by virtue of it's absence)

note that this currently appears to be the very purpose of the
'Incoming_Distros' wiki page[0], although it is presumably incomplete in
this respect, as it does not indicate that any distro has ever been rejected

that suggestion aside, the existing issue i would like to request a
consensus on is this:

the 'Incoming_Distros' wiki page[0] features the following heading:

> Distros that are defunct or do not comply with the GNU FSDG:
>
> This list is those distros which were evaluated and turned out
> not to actually be interested in fully complying with the guidelines,
> and/or project development had stopped:

although all distros currently listed under that heading are in the
"defunct" category and it includes none that "do not comply"; it does
imply that the intention was to record those also, much as the list of
individual projects above - i am trying hard not to indicate a
preference here - i just like rules to be applied consistently - so the
question is: "should that heading be changed to ignore those that were
evaluated but rejected, listing only those that went defunct before
evaluation?" - or perhaps that heading should be removed entirely -
IMHO, those defunct distros are hardly worth mentioning at all after the
fact; and i quite assumed that this page originally served as a buffer
for such short-lived attempts

in order to be consistent - either:

* start itemizing distros that were found not to meet the guidelines
after review, specifying precisely which criteria was not met
* OR, remove the "distros we don't endorse" page and the
'List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines'[3]
wiki page

presumably, the latter is not going to happen; so the only fair thing to
do is, after the review process is complete, to subject any
non-compliant distro to the same "wall of shame" treatment as the
"big-guys" and 

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