On Sun, Sep 7, 2008 at 7:44 PM, Michel Salim <michel.sylvan@xxxxxxxxx> wrote: > On Sun, Sep 7, 2008 at 7:36 PM, Conrad Meyer <konrad@xxxxxxxxxx> wrote: >> Quoth Gregory Maxwell: >>> On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley <aph@xxxxxxxxxx> wrote: >>> > Gregory Maxwell wrote: >>> > >>> >> The notion that firmware ought to be free isn't absurd: It doesn't >>> >> take much effort to find examples of firmware imposing unreasonable >>> >> limits on users, or firmware containing nasty hidden security bugs. >>> > >>> > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a >>> > moment... >>> > >>> > This makes me think of a really interesting question: security- >>> > critical organizations presumably have to make use of commercially >>> > available computers just like the rest of us. Someone somewhere >>> > must have thought about the issues of binary firmware blobs for >>> > video and network hardware and their potential to leak data, >>> > either deliberately or accidentally. One of the many nice things >>> > about free software is the fact that it's reasonably easy to inspect >>> > it for security analysis; binary blobs weaken that. >>> >>> There are two broad classes of 'security-critical organizations', real >>> ones and pretenders. Most are pretenders, they fail to consider issues >>> like this, then when it fails they show that they tried really hard >>> and thus it isn't their fault. Real ones consider these issues, and >>> demand manufacturers comply with various security standards which >>> validate the security of the hardware/firmware. Manufacturers often >>> fail to actually do a good job of this, and can get away with it >>> because bad security looks just like good security. ... so then when >>> it fails the security-critical organization points to the standards >>> that were violated, thus demonstrating the breech was not their fault. >>> :) :) >>> >>> I've found two blobs I use on my systems, one of them very obviously >>> is a FPGA image, another one is appears to be software for a small >>> micro-controller. I'm not so sure that the FSF would consider the >>> FPGA image software, but I don't know that they've considered this >>> issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != >>> software from them in the past), I think the vast majority of the >>> blobs distributed in fedora are software for an embedded general >>> purpose CPU and not FPGA images (generally FPGAs are enough of an >>> additional per-unit cost thet you don't see them in mass market >>> devices). (RME hammerfall firmware is the FPGA image, incidentally). >>> >>> As was pointed out here, a spin could be created easily enough. It >>> would make the FSF happy, as well as some number of other people (it >>> would make me happy, if for no other reason than I'd get a better >>> understanding of which of these blobs I'm actually using). >> >> The spin's already been created, it's called BLAG. >> > That's not really a spin, though, that's a derivative distribution? > The idea of my original flame^H^H^H^H^Hquestion is to see what minimal > changes we can adopt to make GNU happy. If it's too intrusive then of > course it's not really worth it. > > A spin can only contain packages that are taken from Fedora proper, > thus at the minimum we'd need a blob-free kernel. Isolating the other > firmware packages should be easier. Having looked through a number of the blag packages, a good majority of the changes is rebranding components like anaconda. There are a number of changes though that definitely make it qualify as a derivative, such as choosing jack over pulseaudio. -Yaakov -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
