On 10.05.2018 00:17, Julius Werner wrote:
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.
No, it's about convenience, trust, security. Even if you only sign once. If you can get the public key for verification out-of-band, an attacker would have to compromise both, the repository and the key distribution. The signee has nothing more to do than sign it, keep the signature along with the binary. That's easier than comparing hashes.
Otherwise you can just store a list of allowed hashes, which is much easier
That's another way for an out-of-band trust anchor. IMHO more incon- venient but ok if you keep that list far away from the repository.
(and already implicit in Git if you use the coreboot.org blobs repository).
Sounds just more error-prone and inconvenient to me. Sure you can follow hashes in Git, but if you cherry-pick somewhere, you can't. With our process with Gerrit for instance, you'd have to verify that the file that ended up upstream is still the same (doable, sure, but checking another time? I'm getting bored). And where do you store the information that you actually did check? If somebody asks you two years later if you did, what would you say?
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
Who is `you` in "you maintain control"? It's one thing to trust a single person who provided the blob (hopefully the silicon vendor if you need it for a product). But a very different thing to trust everybody who can write to our repository. Or should somebody who checks the hash also check the history of the list? check who changed it? (or who was imper- sonated to change it) Blobs aren't reviewable, are they?
(e.g. you could enforce that they have been tested with coreboot before inclusion).
How? You can make it a rule, yes. But how enforce it?
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.
I don't understand your reasoning here. Ofc, the blob vendor can screw you. But that's the point of blobs, isn't it?
(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.)
No, you understood me correctly. I just want a trustworthy distribution of the binaries.
To wrap it a little up, I really only had the bigger players in mind when I wrote my draft rules. And I understand your point for a one time blob submission (why set a key pair up for that). You get equivalent security with a hash that is distributed out-of-band. So that option should be added if we ever agree on such rules.
Still, if somebody pushes a platform for inclusion on the master branch, and thereby asking to maintain it, I don't see why he shouldn't take the time to sign the blob (ofc, if he runs off later, somebody else (i.e. who already verified the original signature) could take that responsi- bility over).
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.
No idea what you are trying to tell here? I didn't talk about (strong feelings about) violations. But let me clarify my point of view: Everybody with the time and resources to put things into a blob seems to be excluded from the copyleft nature of the GPL (so we don't get much contribution from the big players). Yet, OTOH, we force the more humble that don't have the big resources to adhere to the copyleft. If we accept that, the GPL has failed us and we shouldn't keep it, IMHO.
It's a completely different thing, of course the code meant for something else doesn't work on there.
Yeah, but once this was a free-software project. Which implies that you can adapt the code to something new. Which you can't with a blob.
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.
You really seem to miss the point of free software. As long as everybody adheres to the copyleft, you can do things on your own. If a blob ends up being only useful for a single board, ok. Should somebody be able to sell his product with it, sure. But why should the community maintain that shit (partially on the shoulders of volunteers) if it doesn't pro- vide what free software provides?
Nico