On Friday, June 08, 2012 11:18:18 PM Graham Anderson wrote:
On Friday 08 Jun 2012 20:43:10 Jim Henderson wrote:
On Fri, 08 Jun 2012 22:29:22 +0200, Graham Anderson wrote:
Additionaly, I reject the premise that this new form of restrictions is related to security. UEFI code will be permanently running on any machine that implements it and of course it will be running at level that even your OS will be have to obey. And of course it's all proprietary.
Well, I think whether it's about security or not is debatable (but not actually relevant in the end - because it's coming and that's how it's being /sold/ to the mass market).
The original paladium (TPM) chips were seen as inevitable, and while they have made their way onto many boards that corporations and governments buy (because of the obvious implications of lockdown) these chips have not seen much penetration outside the paranoia of large industry. That in itself is quite amusing because the alleged security that TPM provided, has never come to pass. The penetration of corporate and government networks that specifcy having a TPM chip should raise flags to just about anyone except maybe those that frequent the South China Sea near Taiwan.
A few years on and now we have son of paladium, and that's TPM+UEFI. The hope is that there can be control or monitoring or shutdown of "unauthorised software". It's frankly a pipe dream. And on matters of trust we just have to look to the recent CA's that issue generic certs for cash. And that's just the cheap wankers, flame authors are desperately and efficiently covering their tracks even with government backing.
So i ask you again. Do you really want your bootloader and kernel to only be "authorised" by the likely candidates that will crack your system for political or monitary gain?
Cheers the noo, G
I love your arguments in disfavor using UEFI+SecureBoot or even not so useful TPM I just want ro remind you we can not contlol vendors implementation. They are going to launch 2 options (if they really make it): 1) ARM with Windows8 Certification Logo + UEFI + SecureBoot: On these devices SecureBoot is not going to be possible to disable it "easily". 2) x86 xxx with Windows 8 could include some way to disable SecureBoot.: On these devices an option on UEFI settings might be implemented by hardware vendors. Both options will come to the scenario this year. We (community) could watch what is coming up next months or taking actions to not missing pieces on this map (users market). Options: 1) Buying a Key (something complex to the whole OBS, releases, appliances, customized operating system, etc.). We need to know How To for the whole options we offer. Maybe changing the whole way we work (package approval process to be signed) Yes, I know is crazy and an huge work. 2) Building something able to boot despite Secure Boot (Dream at no cost or highest cost) 3) Complaining before international courts (anti- trust). I don't think there are much partners involved to start it) 4) Keeping us off these limits. I have no read any worries from SUSE Enterprise, or any other associated. And I don't know if they are working on any directions to solve these issues as no oficial communications has been made. Maybe the ARM team on factory have been working on, I could not say it. Any other ideas? Regards, -- Ricardo Chung | Panama Linux & FOSS Ambassador openSUSE Projects -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org