On Wed, Dec 15, 2010 at 10:07:50PM +0100, Patrick Georgi wrote:
Am Mittwoch, 15. Dezember 2010, um 20:17:18 schrieb Xavi Drudis Ferran:
If the later I don't like the idea and at least I would like a huge warning "BLOBS IN HERE !!!" at the end of the make output.
I avoid the term "blob" for two reasons:
I don't quite dislike "blob", but any meaningful alternative would do for the warning. I'm not sure the name of the file alone would do, some sort of taint flag, or license info would be ideal. In fact the best I can dream of is the name of each file, the license and the availability of source (linux has parts nominally under GPL without source code).
But of course source code would need a definition. I seem to intuitionally feel I know it (the GPL definition), but then I find cases of people disagreeing, and they may not all be in bad faith.
I prefer the OpenBSD definition of "blob": binary components that run on the CPU. That a clear line drawn in the sand, and a useful distinction, too. Unfortunately GNU/blob spoiled that.
I don't care where it runs. For me it's more whether it's been derived from some other form and what's more useful to touch if you want to change it. There's also the question of whether it can be replaced, but if it couldn't it wouldn't be included, of course.
<rant> Applying the current FSF use of the word, a graphic rendered to png or jpeg without the source material (vector graphic, gimp image with multiple layers, ...) shipped with it is a blob. We're lucky that we never added a default bootsplash image to the tree!
I don't get your rant. Whether there is source or not does not depend always on the format. If your bootsplash was made with gimp it would be better to include the source (it would be easier to combine with the logo of the hardware owner company, for instance, or adapt to other resolutions...), if it was made with a camera, maybe it's not so necessary to include the raw image and settings.
I had to debate with GNU developers if the S-Boxes in AES are "blobs", and if there's a "preferred format" for them (ie. if they could be calculated). They can't be calculated (there are a couple of formulas to verify if an S-Box is valid, but many are), but if you pick the wrong "valid" one, you get a different (and probably less safe) algorithm. The FSF meaning of the term only scares the same people who use it that way.
</rant>
I think the discussion may have been less interesting to you than to them because you knew the algorithm better, but I think it was a relevant question. For me it would give insight on "where the security comes from" if I had time to learn AES. Must be similar to DES. I've never understood what makes those permutations secure or others less secure.
That there aren't any binary components in the tree is simply for the fact that they're not redistributable: We usually scrap them from vendor BIOSes, and they're not separately available. That won't change.
I hope it does not change even if one day vendors start giving permission to distribute sourceless binaries, as happens in linux or elsewhere. In fact there's already CPU microcode, but I'm not sure what would be "source" for that, so it may be ok.
(It would spark quite a debate when storing binaries in the tree would actually be proposed, but we never even got that far for the stated reason)
Ok. I'm happy to avoid that debate until the choice comes. For me it's enough now to know there won't be binaries in the tree so users will have to opt in. I tried to change the subject header because it's no longer about the patch.
The other fact: Hardware relies more and more on update-able components in flash, without any knowledge of what this is.
And that drove me to coreboot. This is why the project would lose all interest for me if this market trend would be accepted as an excuse for including sourceless stuff. But I guess that the project wouldn't lose much from my loss of interest in it.
Maybe it's 8051 code, maybe it's VHDL stuff of some sorts, maybe a table like the S-Boxes, or a JPEG image. There is no preferred format, there's usually no disassembler for the data, or documentation that can be read outside the high security area at the vendor (and very likely only in 5pt print, orange glyphs on red paper in the area, to prevent anyone from making copies), but there's a single invariant for most of them: Without the data around, your system won't boot - it's useless as a brick, with the only feature that it sucks power.
I'm not arguing the usefulness of hardware without binary stuff in those cases, I'm just arguing the usefulness of free firmware lacking source for components that do have source but it is not public.
If you prefer to live without the file, simply don't put it in there. Your board might be less useful than a brick, but that's your choice.
That brick would at least be useful to develop free replacements for the missing parts :)
The default will be to not ship those files, both because we aren't allowed to redistribute them, and to have a safe default from a license perspective.
Default ? or policy ?
This patch won't change anything in this regard. The plan with the script I outlined is only where I see where this project is heading, for technical reasons. What this patch does is eliminating a bottleneck: Right now we have to maintain a list of files that can be added to the CBFS image at a central location, and that won't scale in the future. Nothing more, nothing less. No feature at coreboot runtime (or misfeature as you'd probably see it) is added or dropped, it's just build system magic.
Thanks for explainig. Yet build system magic may hide important info from the user _if_ binaries are distributed. So as long as they are not, I'm 80 % happy with it (sorry, an old joke from the swpat EU directive). Still helping users install non free software is not nice (as stated in the GNU free system distribution guidelines, for example), although I'd say coreboot users are not so naive as not to notice. Coreboot is not exactly as easy to install as Ubuntu.