Yes, I agree and already did so when writing the above. That's why I made it a recommendation and not a requirement. I also intentionally didn't write "vendor". Just whoever provides the blob should sign it.
I still don't really get what signing in general is solving here. Digital signatures are only useful if you want the signer to be able to make a new release without having to update the thing that's checking the signature. Otherwise you can just store a list of allowed hashes, which is much easier (and already implicit in Git if you use the coreboot.org blobs repository). In the Intel case maybe signing them makes sense, but it shouldn't be a big deal to just maintain a list of FSP releases with their hashes in the coreboot repo either... at least that way you maintain control over which blobs are valid (e.g. you could enforce that they have been tested with coreboot before inclusion). If you just let Intel sign stuff, you're giving them complete control over this thing that I think you intend as a protection for our users. They could sign a special blob for the NSA and you'd never know until you accidentally catch it running on someone's system. (Or do I misunderstand and you're talking about signatures checked at runtime? That wouldn't really make sense on a per blob basis when the rest of coreboot isn't signed, I think. If you want runtime signatures, it's better to use a system like vboot that covers the whole image, coreboot and blobs and all.)
Of course it would be nice if every chipset was implemented well enough that you can bring up a new mainboard without any help from the vendor,
but
that's not always that simple, and I don't think it should be a
requirement
for inclusion.
Sorry, I thought that is what free software is about. Must have been confused to mix that up with coreboot. IMO, blobs are already a huge offense, a disgrace of coreboot and the GPL. But having to sign an NDA to be able to use a GPL licensed project in a product? WTF?!?
I don't care if people think that their loopholes are safe enough and use coreboot that way. But why should the community, including many volunteers, maintain that junk on the master branch?
If that is the attitude moving forward, maybe we should stop licensing new code under the GPL? Just as a courtesy towards free-software develo- pers. And to make it clear for new contributors what they sign up for.
I think you're getting pretty absurd for the sake of argument here. A different mainboard is a completely different device, of course it may not run with the firmware meant for another device. Complaining about this as a GPL violation is like saying that Intel was violating the GPL by adding a Haswell port to coreboot and then not allowing you to support a Skylake board with that. It's a completely different thing, of course the code meant for something else doesn't work on there.
Of course I think we should try to keep blobs mainboard-agnostic, and whenever I have a chance to influence that I do. But it's not always that simple. Often you may not realize that it won't work on another board until you actually build that board and try it out. It's not like anyone is actively preventing or disallowing you from bringing up another mainboard with the same blob that's already there, and if your other board uses 100% the same components as the original then that should always work... but if you find out you need to use some controller or I/O pad that this blob didn't initialize because other mainboards didn't need it, then yeah, sorry, it won't work. It's not like anyone did that intentionally, it's just bad luck. I think this is conceptually the same as when you have a completely blob-free platform but you want to use some peripheral that nobody ever implemented a driver for before. You'll need help from the vendor then as well.