> in case the system isn't yet infected. All the system has to do is > fetch a new kernel and install it somehow, and if it does, even if it > *is* infected, it would work, since the bootloader is assumed to be secure.
What new kernel - the release is by then over a year old so is no longer supported. There will be no new kernel. You could certainly warn/continue, but if that breaks automatic boot of a large server array (eg a high performance cluster) you are back to suqare 1. > > Correct - and you need to lock it down way more than that. Also I can't > > see Red Hat directly signing third party binary blobs. If it does that it > > implicitly believes they are lawful and also acquires some liability for > > them in they malfuction. > > That's a good point, but a little disclaimer would do, wouldn't it? I > mean even today Red Hat shouldn't explicitly support them when it comes > to security. I hope they don't. I don't believe they "support" them at all in most cases, and Fedora doesn't full stop. > That would be, well, extreme. Say if legally OEMs are bound to empower > the user to manage the keys in the firmware, would you still advocate > against the use of the technology? No - user manageable keys are the right way to do it and solve the whole problem. It's also what Matthew and others have been fighting very hard to get into the system. This is how the original debacle about 'trusted computing' was resolved by regulatory pressure. You can put your own keys into a TPM and control and use it for your own purposes. Alan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
