On Aug 6, 2017, Henry Jensen <hjen...@mailbox.org> 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 fighter http://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