On 06/06/12 18:21, C wrote:

Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...

http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro...

What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?

F****** Microsoft again! Is this "blog", or whatever, is now telling me that I have been booting my computer INSECURELY for the past 30 years? The problem here is UEFI. So, get rid of the parasite. There was a reason for why I never used Intel in my computers - but I didn't really know why I never did. It was always a "gut feeling". Well I think I now know why I had this feeling- /quote The original EFI (Extensible Firmware Interface) specification was developed by Intel. Some of its practices and data formats mirror ones from Windows. /unquote Intel, Microsoft, Red Hat.... 'Nuff said. BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 06/06/12 21:23, C wrote:

On Wed, Jun 6, 2012 at 1:15 PM, Basil Chupin wrote:

...

Is this "blog", or whatever, is now telling me that I have been booting my computer INSECURELY for the past 30 years? It's not Swapnil telling you... he's just the messenger. Don't shoot him, he's a member of the openSUSE community too :-)

...

The problem here is UEFI.

So, get rid of the parasite. In a perfect world.. but the harsh reality is, it IS coming, and it will be a part of all hardware in the not so distant future. Supposedly not possible to disable on ARM devices, and can be disabled in the BIOS on all other devices.

We can bury our heads in the proverbial sand, and hope it goes away... or we can face the reality that it will be here regardless of what we think.

So, do we make the best of the situation? Or do we do nothing, and openSUSE simply won't work (unless you're technically savvy enough to register your own keys or know how to bypass UEFI) on new UEFI limited hardware where other distros will?

C.

I take it that it is something which is part of BIOS as we now know it. So, if a manufacturer decides not to provide this abomination in their chip(s) then it would not be a problem and people would then buy systems using these unadulterated chips? There was this thing called DRM introduced a few years ago and for which a crack was released only hours after DRM was first used in a device. Microsoft can go and fly a kite as the world is not that stupid about its intentions. BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wednesday 06 of June 2012 22:18EN, Basil Chupin wrote:

I take it that it is something which is part of BIOS as we now know it. So, if a manufacturer decides not to provide this abomination in their chip(s) then it would not be a problem and people would then buy systems using these unadulterated chips?

If they do, they can't put the "Windows 8 compatible" (or whatever) logo on the box. I'm afraid not many will risk that. It's the same with DVD/BD players: if a manufacturer allows its user (who is actually their customer and pays them for the product) to ignore those extremely annoying "skip of fast forward not allowed here" features, they don't get a certification and can't put a logo on their boxes. See for yourself how many manufacturers go this way... Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wednesday 06 of June 2012 15:20EN, Christian Hueller wrote:

Windows Hardware Certification requirements, page 116 states

"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"

not sure how it will look in reality but I hope that one can simply disable this feature.

As I understand it, this means going into setup and disabling the feature (and perhaps confirm that you understand that it will expose your computer to all kinds of bad guys). It is easy for me or for you. The question, however, is whether we want to require every potential user of OpenSuSE (with sufficiently new hardware) to do this - while Fedora won't. Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Le mercredi 06 juin 2012 à 15:41 +0200, Michal Kubeček a écrit :

On Wednesday 06 of June 2012 15:20EN, Christian Hueller wrote:

...

Windows Hardware Certification requirements, page 116 states

"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"

not sure how it will look in reality but I hope that one can simply disable this feature.

As I understand it, this means going into setup and disabling the feature (and perhaps confirm that you understand that it will expose your computer to all kinds of bad guys).

It is easy for me or for you. The question, however, is whether we want to require every potential user of OpenSuSE (with sufficiently new hardware) to do this - while Fedora won't.

and people using dual boot with Windows 8 will need to enable it back in firmware each time they want to boot Windows 8.. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-06 16:01, Frederic Crozat wrote:

Le mercredi 06 juin 2012 à 15:41 +0200, Michal Kubeček a écrit :

...

On Wednesday 06 of June 2012 15:20EN, Christian Hueller wrote:

...

Windows Hardware Certification requirements, page 116 states

"all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys"

not sure how it will look in reality but I hope that one can simply disable this feature.

As I understand it, this means going into setup and disabling the feature (and perhaps confirm that you understand that it will expose your computer to all kinds of bad guys).

It is easy for me or for you. The question, however, is whether we want to require every potential user of OpenSuSE (with sufficiently new hardware) to do this - while Fedora won't.

and people using dual boot with Windows 8 will need to enable it back in firmware each time they want to boot Windows 8..

So we have to do it, or do it. No way round... - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/PapUACgkQIvFNjefEBxpVdACdFRIzdH5yzIi3WlfmNBXPaFTI /gYAoKwQqVc/8oFu+nnty04Cge5DvaIU =ps8K -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:

The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.

So we will probably have some support like this.

This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...

Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly). Seems like the sort of thing OIN was created to help combat, wasn't it? Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Jim Henderson wrote:

On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:

...

The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.

So we will probably have some support like this.

This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...

Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly).

Yes, very interesting point. There are plenty of such examples. -- Per Jessen, Zürich (18.2°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

C wrote:

On Wed, Jun 6, 2012 at 6:53 PM, Per Jessen wrote:

...

...

On Wed, 06 Jun 2012 14:25:29 +0200, Marcus Meissner wrote:

...

The BIOS vendors likely will need to include it as it is a Windows 8 certification requirement.

So we will probably have some support like this.

This will be fun, as Fedora will be doing signed kernels et al, on how we do this with our quite open buildservice...

Not to mention people who build their own kernels or need customized kernels for hardware on their systems (such as I needed for my Dell laptop to support the touchpad properly).

Yes, very interesting point.  There are plenty of such examples.

Quoting from Swapnil's blog post....

"For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."

Ah, okay. Thanks. -- Per Jessen, Zürich (18.1°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wed, 06 Jun 2012 20:57:19 +0200, Pascal Bleser wrote:

It seems to me to be essentially the same as when you want a TLS certificate for e.g. doing HTTPS: you send a request to a root CA (Certificate Authority) (such as Verisign, Thawte, ...), pay a fee, and they send you back your certificate, signed by them.

In the same way as e.g. Verisign's CA certificate (which is used to verify that _your_ certificate has been signed by their private key) is included in all the CA certificate bundles (by Mozilla for Firefox, by Google for Chrome, by Opera for Opera, for the operating system, ...), Microsoft's CA certificate (or its technical equivalent in UEFI) is included and, hence, trusted, by hardware vendors. I don't know whether there are other CAs that can be asked to sign our openSUSE release images though.

So, about "one time or not": it is one time for each openSUSE release image we want to be installable on hardware that uses UEFI.

For custom images, such as those created by SUSE Studio, it's toast, indeed.

So what if SUSE/openSUSE were to get a signing key signed by Verisign, allowing OBS to issue signing certificates that had a valid chain of trust back to a CA that's on the 'approved' list? Seems that if OBS could just sign kernel images with a valid certificate, that might solve the problem. It might introduce another issue, though - that of someone using OBS to build a 'malware' kernel that was signed by OBS. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wed, 06 Jun 2012 21:19:28 +0200, Bruno Friedmann wrote:

...

So what if SUSE/openSUSE were to get a signing key signed by Verisign, allowing OBS to issue signing certificates that had a valid chain of trust back to a CA that's on the 'approved' list?

Seems that if OBS could just sign kernel images with a valid certificate, that might solve the problem. It might introduce another issue, though - that of someone using OBS to build a 'malware' kernel that was signed by OBS.

Even better, help CACert to get a sub-ca key that work with uefi, and then use that free & open circle of trust.

There's an idea. Since the certificates issued to sign OBS-project builds would be individual certs, if a malware build was released, the key could be revoked, problem solved (as long as UEFI supports certificate revocation) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

I am not sure about the intricate details about UEFI but could the bootloader be signed and then that executes an unsigned kernel? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wed, Jun 06, 2012 at 09:23:40PM -0400, Andrew Joakimsen wrote:

I am not sure about the intricate details about UEFI but could the bootloader be signed and then that executes an unsigned kernel?

This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything. It will get the certificate revoked quite fast (although I do not how they do it). Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Marcus Meissner wrote:

On Thu, Jun 07, 2012 at 06:48:14PM +1000, Chris Jones wrote:

...

I'm not worried too much. The tech industry has a funny way of sorting itself out when it comes to stuff like. Just kick back, grab yourself another drink and wait and see what happens. :-) We are part of the sorting out team though ... ;)

Ciao, Marcus

True, but my comment was more of a generalization targeted towards users who have no say or control of the topic. Cheers Chris -- OpenSUSE Linux x86_64 (PC)|Android (Smartphone)|Windows x86 (Gaming!) Kernel developer|Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web Services|Digital Imaging Services Controllers: Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

* Ricardo Chung [06-07-12 10:34]: ...

Not sure if I want to buy any new computer with those UEFI+SecureBoot implementation looking for another protection layer or taking the risk and going the way we were until no more way is allowed. It's obvious the forces are rising up to reduce options.

And, unfortunately, the security/safety of the hardware system is not probably foremost in the presenter's eyes. It most probably can be *completely* explained as someone saw an opportunity to gain control of something that they could wield to realize financial advantage. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thu, Jun 7, 2012 at 5:32 AM, Marcus Meissner wrote:

On Wed, Jun 06, 2012 at 09:23:40PM -0400, Andrew Joakimsen wrote:

...

I am not sure about the intricate details about UEFI but could the bootloader be signed and then that executes an unsigned kernel?

This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.

It will get the certificate revoked quite fast (although I do not how they do it).

So wouldn't the certificate be revoked if we put it in the OBS and SuSE Studio and let anyone sign their stuff? Also how about malware authors, will their certificates be revoked? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Pay the fee and stop arguing. *Nobody* is going to use a distro if there's an extra hassle to do so. Given that, I'd also expect that Microsoft would sell a virtualization solution for desktops. Why should they lose revenue to VMware Workstation and users to Oracle VM VirtualBox? On Wed, Jun 6, 2012 at 1:21 AM, C wrote:

Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...

http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro...

What are we as openSUSE going to do here?  Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?

C. -- openSUSE 12.1 x86_64, KDE 4.8.3 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

This is to keep Linux out of the coming ARM server market not just the desktop/tablet market. I say we figure out how to manage this requirement and just do it. Steven ____________ Apply appropriate technology. Use what works without prejudice. Steven L Hess ARS KC6KGE DM05gd22 Google Voice 661 769 6201 +SMS openSUSE Linux 12.1 KDE 4.7.2 Known as FlameBait and  The Sock Puppet of Doom. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thu, 07 Jun 2012 16:21:41 -0400, Andrew Joakimsen wrote:

Let's say each kernel/complete packaged os release requires a unique certificate.

I don't expect it'd be a unique certificate per release - the certificate is used for generating a digital signature (checksum + chain of trust), so as long as the certificate is within it's certificate validity interval (I've seen some issued for as few as 2 years and as much as 10 years, though certainly other intervals can be valid as well). The purpose of the signature is to prove that the compiled kernel was built by a trusted source and is unmodified. So being my own "devil's advocate", if we did issue certs (assuming an intermediate signing CA could be approved), what steps would we need to put in place to ensure that those using OBS or Studio were trustworthy? Come to think of it, though, a separate signature probably wouldn't be necessary for Studio as long as a validly signed kernel were used in the build. If a custom kernel were used (from an unofficial repo without a signed key), then that's where the additional kernel would be signed. But the more I think about it, the more I wonder if the official kernels are signed so UEFI could work, whether it would be necessary to have Studio builds have any additional signing done. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thu, 07 Jun 2012 16:50:15 -0400, Andrew Joakimsen wrote:

This goes back to my last message: how do we determine the specifics instead of speculating?

If EFI and UEFI are the same (and it appears they are; EFI was a specification developed by Intel, and UEFI is managed by the UEFI forum as UEFI. So assuming the EFI and UEFI specs are the same, it seems we could answer some of the questions experimentally using VirtualBox, which has EFI support in it. I agree that we need to move beyond speculation and into the realm of determining what practical steps need to be taken. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Jim Henderson wrote:

On Thu, 07 Jun 2012 13:17:41 -0400, Andrew Joakimsen wrote:

...

...

This would kind of defeat the purpose... Then anyone could take this bootloader and boot everything.

It will get the certificate revoked quite fast (although I do not how they do it).

So wouldn't the certificate be revoked if we put it in the OBS and SuSE Studio and let anyone sign their stuff?

If you're referring to the idea I suggested, I wasn't suggesting that a single certificate be used for all of OBS and Studio, but rather that there be a CA server with a trusted chain back to Verisign, and that upon request, Studio and OBS could issue a unique certificate with a valid chain of trust back to Verisign that could be revoked by OBS/Studio if it were abused in some way.

But that assumes that CRLs could be used by UEFI, and it's not clear to me that they could be - since it's implemented in hardware and updating the CRL would require Internet connectivity.

It seems reasonable that CRLs could be retrieved and hardware/firmware updated with an appropriate utility running when the system is up, but OTOH, revoking a certificate in this context seems to be a potentially really dangerous move - disable hundreds-of-thousands of PCs in one fell swoop. Wrt to $SUBJ, I see no problem in the fee itself - if that's what it takes to work on this new hardware without having to disable the secure-whatever. Let us not lose sight of that - as far as I understand, we're not looking to utilize whatever it is UEFI provides, we're only looking to help newbies and other converts overcome an initial hurdle that would otherwise make them go elsewhere. -- Per Jessen, Zürich (17.3°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Jim Henderson wrote:

On Fri, 08 Jun 2012 08:33:49 +0200, Per Jessen wrote:

...

It seems reasonable that CRLs could be retrieved and hardware/firmware updated with an appropriate utility running when the system is up, but OTOH, revoking a certificate in this context seems to be a potentially really dangerous move - disable hundreds-of-thousands of PCs in one fell swoop.

I don't know that we have individually compiled kernels out there that are used on hundreds of thousands of PCs. We'd be talking about (potentially) the users of an individual build service repo.

Sorry, I must have missed the context.

But certainly having a certificate revoked has the potential to render a system unbootable, if the CRL does get updated (and we should find out rather than hypothesize about how that works.

A CRL is typically only valid for e.g. 30 days, some systems (MS Exchange for instance) will not work unless they have a valid CRL. I guess the UEFI spec has a section on the importance/use of CRLs.

...

Wrt to $SUBJ, I see no problem in the fee itself - if that's what it takes to work on this new hardware without having to disable the secure-whatever. Let us not lose sight of that - as far as I understand, we're not looking to utilize whatever it is UEFI provides, we're only looking to help newbies and other converts overcome an initial hurdle that would otherwise make them go elsewhere.

The fee is pennies per installed system (if that), and yeah, I think we should for the distribution just handle it. But beyond the distro, I think it's important to understand the ramifications to systems like OBS and Studio and deal with that as well. That's probably a bigger issue to deal with than the releases of openSUSE with 'official' kernels.

Perhaps users of those could just disable the UEFI secure functionality? I appreciate that dual-booting Windows8 would be an issue, but maybe it would be worth looking at the user or system "demographics" - to gauge the impact. -- Per Jessen, Zürich (17.2°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Fri, 08 Jun 2012 09:14:39 +0000, Jim Henderson wrote:

I'm also wondering, though, how this all fits into using live media as well. If secure boot is enabled in the BIOS, does that prevent DVD/USB booting? (Don't know the answer to that one, but clearly something to consider as well since many people try the LiveCD or build a LiveUSB from the LiveCD to try out openSUSE).

It seems that UEFI fully supports booting from external media even with secure boot enabled. There's an article in the Intel Technology Journal (Vol 15 Issue 1, 2011) entitled "UEFI Networking and Pre-OS Security" that provides a very good overview of how the boot process (and secure boot in particular) works. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

What's the *simplest* solution to the *immediate* problem that will meet the deadline? We need something in place that won't lock us out between 12.2 and the next release. We need something that provides a minimum of hassles in a world where nearly everybody uses something other than openSUSE already. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wednesday 06 Jun 2012 10:21:19 C wrote:

Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so...

http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micro soft

What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet?

I don't believe that the CA authority in question that would need to sign any of our bootloaders is trustworthy at all. I think it will prove to be a mistake to "trust" these technically weak corporations. 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. If I'm mistaken, please correct me. Cheers the noo, Graham

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). If secure boot is enabled for Windows8 and the user keeps Win8 on the machine, then it has to be dealt with by any additional OSes on the system if the Win8 install is going to be booted into with any sort of regularity. If openSUSE is the only OS on the box, then the specifications (and what's been publicly stated) state that for x86 platforms, UEFI secure boot can be disabled by the user. At least that's my understanding of the situation. I think the most useful thing we could do at this stage is see how it's actually implemented on a real (or virtual) system. At least for me, if I can see what it actually does and how it behaves, that gives me a better feel for what there is to actually deal with. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

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

On Fri, Jun 8, 2012 at 5:14 PM, Jim Henderson wrote:

On Fri, 08 Jun 2012 23:18:18 +0200, Graham Anderson wrote:

...

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?

Certainly I don't /want/ that, but at this stage of the game, it seems the stage is set for that to happen.  So rather than push for what I want, it seems reasonable to deal with the hand that's been dealt.

That doesn't mean giving up on what I want - but there is a practical reality to consider, which is if we don't adjust to cope with this new thing, this new thing will keep us from running on people's hardware, and openSUSE will cease being a choice for them.

This is a case where perhaps taking a page from Microsoft's "Embrace, Extend, Extinguish" strategy might be helpful.

Jim

I don't think openSUSE is in a position to "strategize" or even "lead" in this matter. I'm not sure openSUSE is in a position to lead anywhere except with SUSE Studio and Open Build Service. You're right - we either come up with a fix by a certain date or there are people who will *never* run openSUSE. Just out of curiosity, is there an OpenFATE or Bugzilla entry for this? Seems to me it's not a "bug" but a new feature request. Issues have owners, and I don't see anyone stepping up to own this yet. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Sat, Jun 9, 2012 at 4:06 AM, Administrator wrote:

...

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).  If secure boot is enabled for Windows8 and the user keeps Win8 on the machine, then it has to be dealt with by any additional OSes on the system if the Win8 install is going to be booted into with any sort of regularity.

I'm not convinced it's coming, apart from in marketing materials.  The general public have shown remarkably little appetite for the relentless upgrading from one version of your-OS-of-choice to the next, especially with no perceived benefit.  "Security" isn't a major concern for most people using computers & the internet, so it will take major scaremongering or some variety of blackmail to convince people that they should move.

Win7 has only just (or will soon, depending upon who you believe) made it to 50% share, 3 years after release.

We should exclude the major corporate from our consideration as they don't do openSUSE.  Unfortunately, I can't find stats excluding these guys.

David

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

1. Yes, the "post-PC" mass market is in a rapid state of flux, mostly because you can *almost* be as productive as a mobile knowledge worker with a cloud-backed iPad as you can with a 5+ pound $1200US laptop, and the iPad provides a *much* better platform for consuming media. 2. Security on Windows is a major hassle. That's probably the only thing Google's ChromeBooks have going for them - their security model is hassle-free. UEFI is Microsoft's best shot at a hassle-free security model. They're going to push it hard with all the cash and hype they can muster. Linux desktops *are* going to be wounded in the process, and Linux distros that delay dealing effectively with the UEFI issue will simply cease to exist as a force on the desktop/laptop. 3. Only time will tell whether Windows 8 tablets can create new customers and take customers away from iPads. If Microsoft can find insecurities in iOS that aren't in Windows 8 tablets and the Windows 8 tablets are less expensive and more secure, you'd better believe that's going to matter to consumers. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Sun, Jun 10, 2012 at 10:36 PM, C wrote:

On Sat, Jun 9, 2012 at 7:44 PM, M. Edward (Ed) Borasky wrote:

...

2. Security on Windows is a major hassle. That's probably the only thing Google's ChromeBooks have going for them - their security model is hassle-free. UEFI is Microsoft's best shot at a hassle-free security model. They're going to push it hard with all the cash and hype they can muster. Linux desktops *are* going to be wounded in the process, and Linux distros that delay dealing effectively with the UEFI issue will simply cease to exist as a force on the desktop/laptop.

A little more on this topic....

http://www.zdnet.com/blog/open-source/linus-torvalds-on-windows-8-uefi-and-f...

C. -- openSUSE 12.1 x86_64, KDE 4.8.2 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Thanks!! 1. Who owns this issue? 2. What steps need to happen before it is closed? 3. When can we expect closure? The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution. As it stands now, I have little choice but to migrate from openSUSE to Fedora over the next few months because it's not certain a large class of users will be able to use my software collections on bare metal should they desire to do so. At least with Fedora, that possibilty is open. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, 12 Jun 2012 08:33:56 +0200, Per Jessen wrote:

M. Edward (Ed) Borasky wrote:

...

1. Who owns this issue? 2. What steps need to happen before it is closed? 3. When can we expect closure?

The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution.

Unfortunately, we don't really have anyone behind anything, we (the community) have to work out a solution for ourselves.

One question that comes to mind (don't know why it didn't before) - is there something that openSUSE might leverage in the agreement between SUSE and Microsoft? Seems like exactly the sort of thing the technical agreement might be leveraged to address. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, Jun 12, 2012 at 10:51 AM, Malcolm wrote:

On Tue, 12 Jun 2012 17:05:50 +0000 (UTC) Jim Henderson wrote:

...

On Tue, 12 Jun 2012 08:33:56 +0200, Per Jessen wrote:

...

M. Edward (Ed) Borasky wrote:

...

1. Who owns this issue? 2. What steps need to happen before it is closed? 3. When can we expect closure?

The community needs answers - at the very least, names of the decision makers. See Distrowatch Weekly this week (http://distrowatch.com/weekly.php?issue=20120611) for the remarks of Chris Smart, the man behind the Kororaa distribution.

Unfortunately, we don't really have anyone behind anything, we (the community) have to work out a solution for ourselves.

One question that comes to mind (don't know why it didn't before) - is there something that openSUSE might leverage in the agreement between SUSE and Microsoft?

Seems like exactly the sort of thing the technical agreement might be leveraged to address.

Jim

AFAIK openSUSE needs to take the lead as they are upstream ;)

Might be time to start a thread in the Factory ML to consider the technical aspects?

Maybe a forum poll to see how many have UEFI bootable systems or plan on buying hardware to run the other OS....

Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....

-- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default up 22:05, 3 users, load average: 0.61, 0.42, 0.38 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

I'd have to go read through the Fedora postings again, but as I understand it, the Fedora community and the Red Hat corporation *collaborated* to forge a solution *and* defend it in the press against the inevitable howls of people who don't understand the pragmatics of either running a business or developing open source software. ;-) I think that's what needs to happen here - the openSUSE community and Attachmate / SUSE corporate need to collaborate on a solution. I'm way down here on the food chain and I have to trust those with the experience and authority to come up with something that will work for me. The fact of the matter from my position is that if my laptop dies and I'm forced to buy a new Windows 8 laptop, at the moment I will be unable to install openSUSE on it. It's about a year old and I typically only get two years out of them because I buy low-end ones. So Linux probably has a year to get their act together for *me*, but for the world at large, I think Linux needs to be UEFI-ready as soon as Windows 8 hardware starts shipping in volume. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, Jun 12, 2012 at 9:17 PM, Ricardo Chung wrote:

You should be able to enable/disable the SecureBoot option on UEFI with no further issues.

That assumes that: 1. The manufacturer puts that option into the UEFI setup (it's not mandatory, from what I read, that they allow you to disable it... they can allow it.. or not...it's only on Arm that they currently cannot allow it to be disabled if they want the Win8 Certified logo.. which they all want) 2. The end user is aware of this requirement to disable UEFI 3. The end user is capable of disabling UEFI The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.

The core issue is not on Windows 8 laptops. It's the specification  ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.

Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.

Operative word there being "may".

Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.

I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again. If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project. C. -- openSUSE 12.1 x86_64, KDE 4.8.3 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, 12 Jun 2012 14:17:38 -0500 Ricardo Chung wrote:

...

...

Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....

You should be able to enable/disable the SecureBoot option on UEFI with no further issues.

You would think.... http://paste.opensuse.org/96506247 -- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default up 1 day 0:04, 3 users, load average: 0.24, 0.26, 0.28 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-12 21:48, C wrote:

On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. <> wrote:

We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)

That's clear to me and many, I guess. What is not clear is the mechanics of it. Like what is certified, grub, or the kernel. Have you got to pay again for each version. etc. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/XoegACgkQIvFNjefEBxow+wCfYsEbInYZZH3tVV3FPKIpZxqs GmIAoMGW3Ni/iGH1XH91AdvAbqyfoIE9 =9+8A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tuesday, June 12, 2012 09:36:09 PM C wrote:

On Tue, Jun 12, 2012 at 9:17 PM, Ricardo Chung wrote:

...

You should be able to enable/disable the SecureBoot option on UEFI with no further issues.

That assumes that: 1. The manufacturer puts that option into the UEFI setup (it's not mandatory, from what I read, that they allow you to disable it... they can allow it.. or not...it's only on Arm that they currently cannot allow it to be disabled if they want the Win8 Certified logo.. which they all want)

Completely true.

2. The end user is aware of this requirement to disable UEFI

Just a small correcitons. It's to disable the SecureBoot on UEFI. UEFI is the new BIOS equivalent capable to handle the devices connected and the way it communicate each other with the operating system.

3. The end user is capable of disabling UEFI

Again, you should switch UEFI to SecureBoot.

The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.

As far as it's tested, LiveCD are not impacted. Said so, you could be able to boot a LiveCD to play it Live Only. Not installing it. Though is possible it will change next months. You are right. New users and not experienced enough will stop themselves to go beyond if they receive too many scary messages or not messages at all during boot process.

...

The core issue is not on Windows 8 laptops. It's the specification ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.

Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.

Operative word there being "may".

Right. Vendors "may". There is no obligation from Anti-trust Courts or anyone.

...

Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.

I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again.

If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project.

Completely agreed. If we don't have a better wildcard to play that's the way it should go and problably making a public statement from SUSE because at the end it is a commercial issue impacted. Note: Anyway the user needs some minimal technical knowledge to able and/or to disable SecureBoot from UEFI. And this is another point of concerns for the next future operating system releases.

C.

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

On Tuesday, June 12, 2012 02:47:58 PM Malcolm wrote:

On Tue, 12 Jun 2012 14:17:38 -0500 Ricardo Chung

wrote:

...

...

...

Note I'm running UEFI boot with elilo here with openSUSE and SLED, just haven't enabled the scary BIOS screen to enable the secure firmware side....

You should be able to enable/disable the SecureBoot option on UEFI with no further issues.

You would think.... http://paste.opensuse.org/96506247

That picture shows once it key signature option (SecureBoot) is enabled there is no way to go back to unsigned option to boot any not signed operating system. 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-12 22:37, Ricardo Chung wrote:

On Tuesday, June 12, 2012 02:47:58 PM Malcolm wrote:

...

You would think.... http://paste.opensuse.org/96506247

That picture shows once it key signature option (SecureBoot) is enabled there is no way to go back to unsigned option to boot any not signed operating system.

What is secured there is flashing the bios, IMO. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Xqz8ACgkQIvFNjefEBxrKLACfUM2OLApRL4nOgeimdhKkkoYT GYMAn05R10mY/lrlVluS5rSMjrov5yKS =9s5X -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, 12 Jun 2012 12:51:21 -0500, Malcolm wrote:

AFAIK openSUSE needs to take the lead as they are upstream ;)

My thinking here is that the openSUSE community has taken a lot of guff as a result of the Novell/MS (now SUSE/MS) deal - so we should be able to benefit from the deal as well. A collaboration between openSUSE, SUSE, and MS would seem a way to move things forward - SUSE needs us to be able to boot in those environments since we're upstream to them, and it would be a good sign of support of the openSUSE project (not that SUSE doesn't continually show good signs of support to the project, quite the contrary). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tuesday, June 12, 2012 10:47:28 PM Carlos E. R. wrote:

On 2012-06-12 22:18, Ricardo Chung wrote:

...

As far as it's tested, LiveCD are not impacted. Said so, you could be able to boot a LiveCD to play it Live Only. Not installing it. Though is possible it will change next months.

Mmm... this doesn't make much sense, booting anything is dangerous, it could be a virus. This is what they are trying to protect, people booting unsecured things. Once a malware boot code in a CD boots it can do lots of damage to a computer.

That's becasue I said it's possible they change it the next months. MS is considering to launch a total new toolset to protect their installed system. I'm speculating now, they trust their toolset enough. As sample, http://www.zdnet.com/blog/microsoft/microsoft-kicks-off-beta-of-new-windows-... encryption-tool/12908 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

Well If I right understood, this new secure feature, deep impact and affect the computer manufacturers too like, IBM, DELL, HP, POSITIVO, and many others that already provide their Linux offers at the same machine. I believe this new boot feature that only make people able to boot and install OSs if it is already signed by someone, will not be so good to hardware machine builders companies, because the manufactures will loose the power and flexibility of Linux in their offers also make them unable to provide any kind of support or not, or at least they will need to change something in theirs strategy to be compliant with a company like microsoft that has nothing related with their business? In some countries we have an common selling practice and strategy called "Venda Casada"[1] something similar to "linked sale" or "cross-selling" that is not legally in some countries "Cross-selling is when additional products and/or services are offered to the customer in order to meet specific needs associated with the original service request." The question is, there is no law that make this feature illegally? If manufactures starts to know about that and refuse to implement this "secure boot" feature into their products like IBM, Dell, POSITIVO, HP so maybe Microsoft starts to think in another way to implemented such thing without forcing these companies to be dependent of this company. Of course we need to keep looking for a technical solution, but also I think is a good idea to start to think about political, economical and based on specifics laws solutions to help us to keep the freedom of choice and diversity on top of humanity needs instead of "secure". I remember that sometimes in past customers power makes companies to do unbelievable agreements that we could never imagine, and I'm not talking if their agreements was good or not, just unpredictable. Another point is that some big, huge, enormous customers of these manufactures like walmart, casas bahia, petrobras and many others around the world have heterogeneous IT infrastructure and probably they will not be happy to know that in few time they will not more be able to have freedom of choice about which OS they will run or flexibility to change from one to another one. So this is not only about 99 pieces of a value metal, depending of the point of view could be also a problem to some companies strategy and freedom to run their business just like they want and not imposed by other company that have nothing related with their market or business and could be a legal issue too. How many companies are building their solutions using SUSE Studio, how many building their solutions with kiwi, obs. ? Makes sense to involve companies that are running obs and studio? Do they will effectively be affected? [1] http://pt.wikipedia.org/wiki/Venda_casada CarlosRibeiro 2012/6/12 Jim Henderson :

On Tue, 12 Jun 2012 12:51:21 -0500, Malcolm wrote:

...

AFAIK openSUSE needs to take the lead as they are upstream ;)

My thinking here is that the openSUSE community has taken a lot of guff as a result of the Novell/MS (now SUSE/MS) deal - so we should be able to benefit from the deal as well.

A collaboration between iopenSUSE, SUSE, and MS would seem a way to move things forward - SUSE needs us to be able to boot in those environments since we're upstream to them, and it would be a good sign of support of the openSUSE project (not that SUSE doesn't continually show good signs of support to the project, quite the contrary).

Jim

--  Jim Henderson  Please keep on-topic replies on the list so everyone benefits

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, 12 Jun 2012 19:04:19 -0300, Carlos Ribeiro wrote:

Of course we need to keep looking for a technical solution, but also I think is a good idea to start to think about political, economical and based on specifics laws solutions to help us to keep the freedom of choice and diversity on top of humanity needs instead of "secure".

I agree that there are potential legal issues here as well (which is something SUSE and The Attachmate Group need to address). This entire feature smells to me like an attempt at more anti-competitive behaviour on MS' part (especially on ARM). But until some court rules that it is actually anti-competitive, the technical challenge remains, and for the openSUSE project, the technical issues are something we need to work out - on our own or with SUSE's help. Just seems to me that SUSE really could help us with this. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, 12 Jun 2012 15:28:32 -0700, M. Edward (Ed) Borasky wrote:

I don't know about other parts of the world, but in the USA there is only one *customer* that has the power to modify vendors' behavior - the US Federal Government.

Not strictly true, try being a vendor to Walmart. ;) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 13/06/12 05:48, C wrote:

On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. wrote:

...

On 2012-06-12 21:36, C wrote:

...

The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many. The problem is that if that person wants to later boot the Windows 8 they bought, they can't until they re-enable uefi secure booting. So... even more reason we need to step up and support this UEFI thing.

We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)

C

My question is: What does the EU think about all of this? Does the EU see this as yet another attempt by Microsoft to monopolise the market? BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Basil Chupin wrote:

On 13/06/12 05:48, C wrote:

...

...

...

The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many. The problem is that if that person wants to later boot the Windows 8

On 2012-06-12 21:36, C wrote: they bought, they can't until they re-enable uefi secure booting. So... even more reason we need to step up and support this UEFI

On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R. wrote: thing.

We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)

C

My question is:

What does the EU think about all of this?

Does the EU see this as yet another attempt by Microsoft to monopolise the market?

Except for a few discussions/blogs, I have been unable to find much/anything on that topic (EU & Secureboot), but at a glance it does seem like something the EU ought to take a closer look at. Especially the key management and the potential exclusion of non-MS or non-corporate software. -- Per Jessen, Zürich (12.4°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:

So why, suddenly, is this UEFI-thing come to the forefront? Nobody knew about this UEFI-thing beforehand, and now, out of the blue, Microsoft comes out with it - and everybody is supposed to go into panic mode?

Has someone been "asleep at the wheel", or am I missing the point about all this?

This is not a new or unexpected innovation. This is an extension of the Palladium/TMP/Trusted Computing[1] innitiative to lock down computers so that only software in userland can be run without the absolute permission of the hardware and operating system vendor. There are numerous real life applications for this technology such as intelligence, millitary, anti-malware, digital rights restrictions and so forth. The list of companies contributing to this in the link provided should raise a few eyebrows at least, for some of them this is about security, for others this is about control. None of it is about freedom of computing. The objections that many, including myself, have to this technology is that you are absolutely handing control of your hardware over to a select band of corporations and their vested interests by enabling secure boot via TPM, signed boot loaders and kernels. This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own. Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys? The implications for free software, privacy and industrial espionage may be far reaching and severe. How do you know what your hardware is doing if you cannot interrogate it without permission? How do you know what your operating system is doing if you cannot run code in kernel space without permission? Yes, I'm paranoid, but history, corporate behaviour and growing evidence suggest that I'm probably right to be so. [1] http://en.wikipedia.org/wiki/Trusted_Computing_Group [2] http://en.wikipedia.org/wiki/Huawei#Security_concerns

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-13 04:30, Malcolm wrote:

According to this, if I want to roll my own... I need to pay up as well... http://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot

"A healthy dynamic of the Linux open source development model is the ability to roll-your-own. For example, users take Fedora and rebuild custom variants to meet personal interest or experiment in new innovations. Such creative individuals can also participate by simply enrolling in the $99 one time fee to license UEFI. For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost."

Not sure about the intentions of the last sentence though.... to me that indicates I can create my own key at no cost and boot to linux as well as use an MS signed key for windows 8... which sort of negates the need?

I understand that you may add your local certificate somehow, valid only for you. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/YdXYACgkQIvFNjefEBxo3vQCfbsDOqkvj+O8ZEoMTKgV6do3h 9DUAniuM0lkHADtipGpeg8223otqtTTh =QvFD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tuesday 12 June 2012 21:36:09 C wrote:

On Tue, Jun 12, 2012 at 9:17 PM, Ricardo Chung wrote:

...

You should be able to enable/disable the SecureBoot option on UEFI with no further issues.

That assumes that: 1. The manufacturer puts that option into the UEFI setup (it's not mandatory, from what I read, that they allow you to disable it... they can allow it.. or not...it's only on Arm that they currently cannot allow it to be disabled if they want the Win8 Certified logo.. which they all want) 2. The end user is aware of this requirement to disable UEFI 3. The end user is capable of disabling UEFI

The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many.

...

The core issue is not on Windows 8 laptops. It's the specification ARM Architecture+Window 8 Certification Logo+UEFI+SecureBoot. This special scenario will come with a SecureBoot not able to deactivate on UEFI or any other ways.

Other architectures like x86 may be coming with the option to deactivate SecureBoot on UEFI.

Operative word there being "may".

...

Any concerns related to boot other operating systems than Windows 8 with Certification Logo must be addressed to get a key registered with Microsoft Keys Manager. At this right moment, it seems no other options cost-effective feasible and available.

I agree 100% here. We should stop waffling... buy the darned key and let's get on with implementing it into the standard openSUSE releases. We can be ready on time for the releases - which are happening later this year... or we can play catchup.... again.

If we don't have enough money in the marketing budget or wherever, then ask on the project list.. I'm sure that one or several of us could cough up the $99 US to cover it for the project.

Sensible. I'll try and bring this up with SUSE, see if MS can indeed help us with this. Seems to me like we simply would have to do what Fedora did.

C.

On 14/06/12 00:35, Ricardo Chung wrote:

On Wednesday, June 13, 2012 03:02:10 PM Basil Chupin wrote:

...

On 13/06/12 05:48, C wrote:

...

On Tue, Jun 12, 2012 at 9:41 PM, Carlos E. R.

wrote:

...

...

The typical scenario is... someone buys a computer.. wants to try out this Linux thing they've heard of.. .pops a LiveUSB/CD/DVD in and boots it up.. UEFI pops up with whatever dire warning the manufacturer put in... "You are attempting to boot an unauthorized operating system, system halted" or some such scary message. How many will twig and say "oh right.. press Del during boot.. find and disable UEFI and boot again"... not many. The problem is that if that person wants to later boot the Windows 8

On 2012-06-12 21:36, C wrote: they bought, they can't until they re-enable uefi secure booting. So... even more reason we need to step up and support this UEFI thing.

We can argue about the semantics of it until the end of time.. is it right or wrong... and in a perfect world we'd say "no we won't go along with this initiative" but.. it's here already.. so... lets just get on with it and pay the fee, get the key... set it up so we can boot and be able to say we support Secure Boot :-)

C My question is:

What does the EU think about all of this?

Does the EU see this as yet another attempt by Microsoft to monopolise the market?

BC I have been following the UEFI+SecureBoot stuff several months ago. And certainly I have not heard anything from EU or any International rulers. Mostly the whole interaction is coming from Hardware Vendors, Software Developers and Press.

Regards,

Thanks for the response. So in the end it may just be some FUD? Quite apart from the EU et al, what has the FOSS come up with re this issue? BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 13/06/12 21:09, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-06-13 12:30, Graham Anderson wrote:

...

On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:

...

Has someone been "asleep at the wheel", or am I missing the point about all this? They have been fighting malware since... ever, and losing. Each time they release a new Windows version they boast of new security and antimalware features, than later fail or don't meet expectations.

...

...

This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own. Right.

...

Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys? Right as well.

But all that is irrelevant. The technology is here this cycle and we can not avoid it, so we need to run with it.

Again, have I been missing something in all of this? Has there been a definitive statement about what *exactly* is going to occur? Or whatever is being written about simply speculation and hearsay? I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong? BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 15/06/12 00:09, Malcolm wrote:

On Thu, 14 Jun 2012 23:33:45 +1000 Basil Chupin wrote:

...

I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong?

Hi Correct, only for new systems/hardware that users wish to run Windows 8 as well as other OSes.

Usage of correct terminology here seems to be of vital importance considering all the kerffuffle being written so far by people in this thread :-) . Are you saying that the problem only affects those who want to DUAL BOOT (or run anything-Windows in a VM environment) with anything-Windows when using any Linux distro as their main operating system? or are you saying that this crap will apply to any new mobos in the coming months which not only may want to use Windows 8 but to any other operating system of whatever flavour including a Linux system which they may want to install?

On this DELL E5510 my concern is that it appears I can't disable..... and it's only a concern, I only run linux on this machine...

Which is what is confusing. If you only run Linux then why would you want to disable it? - especially as you are not using one of these yet-to-come UEFI enabled gizmos? (Actually, my mobo has this UEFI on it but I haven't looked at it yet.) I am still confused by the fact that there has not been much stomping of feet and gnashing of teeth about this matter and that people at Fedora have made decisions about this while openSUSE has only this week suddenly woken up that something has to be done about this (if anything that is); not to mention that FOSS has been silent about it (at least I haven't seen any articles re their thinking) and the EU has not been stirring the pot about it. Is all this just a storm in a tea cup or a serious thing? BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Fri, 15 Jun 2012 01:02:10 +1000, Basil Chupin wrote:

Are you saying that the problem only affects those who want to DUAL BOOT (or run anything-Windows in a VM environment) with anything-Windows when using any Linux distro as their main operating system? or are you saying that this crap will apply to any new mobos in the coming months which not only may want to use Windows 8 but to any other operating system of whatever flavour including a Linux system which they may want to install?

Dual-boot and systems with Win8 preinstalled. Even if you want to replace the installed Win8, the user has to disable the secure boot feature if we don't sign whatever it is that needs to be signed, which means we need to teach them how to do this (AIUI, it /must/ be disabled in the BIOS and can't be done from the installer or a running OS). So the scenarios are: 1. New system with no OS on it - secure boot is probably disabled and not a concern. 2. New system with Win8 on it - Secure boot is enabled and has to be disabled in order to install openSUSE, regardless of whether it's a replacement of Win8 or a dual-boot configuration Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thu, 14 Jun 2012 11:23:58 -0500 Malcolm wrote:

At present if I was to enable a signed key system with windows 8, openSUSE and SLE along with virtualization, the way I see it I would need signed keys from;

1 - DELL 2 - Microsoft 3 - openSUSE 4 - SUSE 5 - VirtualBox 6 - Me for any customized kernel modules

Hi I guess there is a number 7, any third party kernel modules would need to be signed... so for example a hardware provider decides to not provide a signed kernel driver for say a RAID card, one would imagine you could run into an issue.... -- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default up 1 day 13:36, 3 users, load average: 0.29, 0.19, 0.24 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-14 19:36, Per Jessen wrote:

Carlos E. R. wrote:

What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.

I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/aUGUACgkQIvFNjefEBxrRrQCfSkp7ET0ggUwkOjTmaGlcw4gj W8AAn0ZWGw7+tH8nSk4SV7VLfL66CsnF =Zk2N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thursday, June 14, 2012 11:27:30 PM Basil Chupin wrote:

On 13/06/12 20:30, Graham Anderson wrote:

...

On Wednesday 13 Jun 2012 15:21:12 Basil Chupin wrote:

...

So why, suddenly, is this UEFI-thing come to the forefront? Nobody knew about this UEFI-thing beforehand, and now, out of the blue, Microsoft comes out with it - and everybody is supposed to go into panic mode?

Has someone been "asleep at the wheel", or am I missing the point about all this?

This is not a new or unexpected innovation. This is an extension of the Palladium/TMP/Trusted Computing[1] innitiative to lock down computers so that only software in userland can be run without the absolute permission of the hardware and operating system vendor.

There are numerous real life applications for this technology such as intelligence, millitary, anti-malware, digital rights restrictions and so forth. The list of companies contributing to this in the link provided should raise a few eyebrows at least, for some of them this is about security, for others this is about control. None of it is about freedom of computing.

The objections that many, including myself, have to this technology is that you are absolutely handing control of your hardware over to a select band of corporations and their vested interests by enabling secure boot via TPM, signed boot loaders and kernels.

This technology may prove to be both a blessing and a curse. On one hand you can reduce the attack vectors and make computer systems more secure; on the other hand consumers are now having to ask permission from technology corporations, and by extension the interests that pressure them (entertainment corporations, governments, intelligence services etc...) to use the hardware you already own.

Additionally, how can you trust the harware implementation to not have back doors[2] in it anyway? And do you really trust the certificate authority given that some of root CA's in SSL chains have already been giving out generic certificates for cash for the express purpose of man-in-the-middle attacks. Do you trust Verisign to never give their signing keys to the US Government or intelligence services? Do you trust them enough to assume that no other nation state such as China has not already compromised them and can appropriate the signing keys?

The implications for free software, privacy and industrial espionage may be far reaching and severe. How do you know what your hardware is doing if you cannot interrogate it without permission? How do you know what your operating system is doing if you cannot run code in kernel space without permission?

Yes, I'm paranoid, but history, corporate behaviour and growing evidence suggest that I'm probably right to be so.

No need to feel that you are paranoid about this, Graham. It is exactly how I feel - and there must be tens of thousands of others as well who feel the same - about the whole thing.

I can almost guarantee that if this scheme was deviced by some company in China then the whole sheebang would be ridiculed, thrown out of consideration as a cyber warfare weapon and what not.

...

[1] http://en.wikipedia.org/wiki/Trusted_Computing_Group [2] http://en.wikipedia.org/wiki/Huawei#Security_concerns

BC

Being paronoid is smart on these days. Trying not to be is not so smart. We need clear criteria to know that. There is enough technological devices tracking or collecting data from us every moment. Some of those devices are not user controlled. In other case, we pay some services to be tracked or collecting our data. OTOH, In case anyone is interested. The last reflections Mathew Garrett has posted about SecureBoot on this link http://mjg59.dreamwidth.org/13061.html 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

On Thu, 14 Jun 2012 17:10:55 +0000, Jim Henderson wrote:

So the scenarios are:

1. New system with no OS on it - secure boot is probably disabled and not a concern.

2. New system with Win8 on it - Secure boot is enabled and has to be disabled in order to install openSUSE, regardless of whether it's a replacement of Win8 or a dual-boot configuration

I wonder what the risk is of a signed component going wrong/not validating - what would the recovery would be for such a scenario? What I remember from reading the specs over, it seems that preserving a previous set of signed components (whatever there is that's needed) would be a good idea. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 15/06/12 14:29, Jim Henderson wrote:

On Thu, 14 Jun 2012 17:10:55 +0000, Jim Henderson wrote:

...

So the scenarios are:

1. New system with no OS on it - secure boot is probably disabled and not a concern.

2. New system with Win8 on it - Secure boot is enabled and has to be disabled in order to install openSUSE, regardless of whether it's a replacement of Win8 or a dual-boot configuration I wonder what the risk is of a signed component going wrong/not validating - what would the recovery would be for such a scenario?

What I remember from reading the specs over, it seems that preserving a previous set of signed components (whatever there is that's needed) would be a good idea.

Jim

If you have to do an addendum to what you wrote only a few minutes ago then can you understand my confusion - and I cannot be alone on this - about this whole matter? :-) What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve! Where is "the Board"? Where is "the Foundation"? Where is anyone who actually knows what is going on and what has to done about this situation? Oh, right...one must not ask questions like this... not the sort of questions one asks in polite company..... Asking questions like this only gets you the title of "troll"...... BC -- Using openSUSE 12.1 x86_64 KDE 4.8.4 and kernel 3.4.4 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 15/06/12 03:36, Per Jessen wrote:

Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-06-14 15:33, Basil Chupin wrote:

...

I read - at least I am sure that that is what I read - that one would be able to disable this UEFI-thingie if one doesn't want to use it. Meaning that if one was to only use a Linux system then one wouldn't need this crap. Is this right or wrong? As far as I know, it is correct, it only affects those that double boot to Windows 8. And the understanding is that they would need to disable the feature to boot Linux, and reenable to boot Windows 8 - every single time. This is unverified yet. What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.

"Unverified". And yet "the comminuty" is being asked how to solve this "unverified" problem. Akin to the situation of the blind leading the blind. I don' know what it all means. Carlos does not know what it all means. Jim doesn't know what it all means. You don't know what it all means. Who does know? Perhaps Jos who seems to know everything. BC -- Using openSUSE 12.1 x86_64 KDE 4.8.4 and kernel 3.4.4 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

2012/6/19 Basil Chupin :

On 15/06/12 08:58, Malcolm wrote:

...

On Thu, 14 Jun 2012 22:58:13 +0200 "Carlos E. R." wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-06-14 19:36, Per Jessen wrote:

...

Carlos E. R. wrote:

...

What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process.

I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.

Hi That was me, the way I understand (and I hope I'm wrong)

But you are not sure, right? :-)

...

 it is, that is the key signature option (SecureBoot) that is in my current BIOS... just one way for me if I used it.....

But you aren't sure, right? :-)

...

There must be other folks on the list with UEFI in their BIOSes... what options do they have?

I ever joined some UEFI event and talked to some of the bios engineer wrt secure boot options in bios. As far as I know the option varies from ODM, but in bios there would be three possible options to "circumvent" secure boot .. I saw one of the bios vendor presented these options to us. 1. Disable Secure Boot Means bios would allow files failed in authentication to execute, but there would be warning message when you attempt to do so 2. Set to Legacy or Dual (Legacy + UEFI) mode Which implies disable secure boot, as secure boot implementation requires running in pure UEFI mode (no legacy emulation module exist). This is also promise to the Windows 7 to run I think. 3. Add files to hash table Allow user manually add file hash to db and allow to run in secure boot enabled mode. But I must say it's unsure whether those options is common, OEM would custom their bios to offer different options and I think above just possibilities. Thanks, Michael

Beats me! :-[

But you don't know either, right? :-D

And you and I, and Carlos and Per and Jim are all part of "the community" - and we haven't a damn idea of how it is all supposed to work :-) .

BC

-- Using openSUSE 12.1 x86_64 KDE 4.8.4 and kernel 3.4.4 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson wrote:

...

What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!

From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.

Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting -- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default up 1 day 21:34, 2 users, load average: 0.36, 0.37, 0.33 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 06/19/2012 06:17 PM, Malcolm wrote:

On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson wrote:

...

...

What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!

From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.

Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting

Michael Chang and some others in SUSE are looking into this and will propose a solution - for both SUSE and openSUSE. If you like to work with them, please speak up. Otherwise, I think the project meeting is the wrong place for this, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 06/20/2012 03:15 PM, Malcolm wrote:

On Wed, 20 Jun 2012 09:43:38 +0200 Andreas Jaeger wrote:

...

On 06/19/2012 06:17 PM, Malcolm wrote:

...

On Tue, 19 Jun 2012 15:58:07 +0000 (UTC) Jim Henderson wrote:

...

...

What I really cannot understand is that this appears to be a major problem with respect to using openSUSE and yet this whole question has been pushed onto "the community" to try and resolve!

From a practical standpoint, the openSUSE community is who builds the distribution. Some of the key people are SUSE employees, to be sure, but a community-based solution for a community-based distribution makes sense.

Hi That's why I added a couple of topics on next weeks project meeting... hopefully we will get a good attendance on IRC. http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting

Michael Chang and some others in SUSE are looking into this and will propose a solution - for both SUSE and openSUSE. If you like to work with them, please speak up.

Otherwise, I think the project meeting is the wrong place for this, Andreas Hi Andreas

Thanks for the information, for sure I'd be happy to help if I can :)

Is there a Mailing List for this?

Talk with Michael directly, Andreas

I will remove the two topics from the meeting topics.

-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 19/06/12 18:19, Michael Chang wrote:

...

On 15/06/12 08:58, Malcolm wrote:

...

On Thu, 14 Jun 2012 22:58:13 +0200 "Carlos E. R." wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-06-14 19:36, Per Jessen wrote:

...

Carlos E. R. wrote:

...

What is not also not verified is if this is a one-way process or not. Somebody sent a screen shot indicating it is a one-way process. I saw it, but I think it is not the same thing. I believe it was for the process of flashing the bios.

Hi That was me, the way I understand (and I hope I'm wrong)

But you are not sure, right? :-)

...

it is, that is the key signature option (SecureBoot) that is in my current BIOS... just one way for me if I used it.....

But you aren't sure, right? :-)

...

There must be other folks on the list with UEFI in their BIOSes... what options do they have? I ever joined some UEFI event and talked to some of the bios engineer wrt secure boot options in bios. As far as I know the option varies from ODM, but in bios there would be three possible options to "circumvent" secure boot .. I saw one of the bios vendor presented

2012/6/19 Basil Chupin : these options to us.

1. Disable Secure Boot

Means bios would allow files failed in authentication to execute, but there would be warning message when you attempt to do so

2. Set to Legacy or Dual (Legacy + UEFI) mode

Which implies disable secure boot, as secure boot implementation requires running in pure UEFI mode (no legacy emulation module exist). This is also promise to the Windows 7 to run I think.

3. Add files to hash table

Allow user manually add file hash to db and allow to run in secure boot enabled mode.

But I must say it's unsure whether those options is common, OEM would custom their bios to offer different options and I think above just possibilities.

Thanks, Michael

Thank you, Michael, for this explanation. But, as you state, there is no consensus as to what is going to happen, and only 1 vendor proffered the 3 options you mentioned. BC -- Using openSUSE 12.1 x86_64 KDE 4.8.4 and kernel 3.4.3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 06/22/2012 02:26 PM, Basil Chupin wrote:

[...] Who is the "legal team" employed by/responsible to?

opensuse-bar is their mailing list, if you have specific questions or are a lawyer yourself and like to join the team, use that list. Currently it's primarily Ciaran doing this for openSUSE - employed by SUSE. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 23/06/12 04:52, Andreas Jaeger wrote:

On 06/22/2012 02:26 PM, Basil Chupin wrote:

...

[...] Who is the "legal team" employed by/responsible to?

opensuse-bar is their mailing list, if you have specific questions or are a lawyer yourself and like to join the team, use that list.

Currently it's primarily Ciaran doing this for openSUSE - employed by SUSE.

Andreas Thank you, Andreas.

I just came across this: https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html BC -- Using openSUSE 12.1 x86_64 KDE 4.8.4 and kernel 3.4.3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Fri, Jun 22, 2012 at 9:59 PM, Basil Chupin wrote:

On 23/06/12 02:33, Jim Henderson wrote:

...

On Fri, 22 Jun 2012 22:39:17 +1000, Basil Chupin wrote:

...

But, as you state, there is no consensus as to what is going to happen, and only 1 vendor proffered the 3 options you mentioned.

Looks like Canonical is now involved in solving it for Ubuntu - they're going to use efiboot it looks like, which apparently (from a slashdot article, so follow the link to the "real" story) means they only need to sign the bootloader and not the kernel.

But that is likely to make things difficult for multi-boot Linux users, if the distros have different solutions and require different bootloaders.

Jim

As long as the most recently installed bootloader: 1. Is legal, paid for, blessed by all the attorneys, accountants, etc. and 2. Can find and boot everything that was bootable before it was installed I'd say everyone should be happy. I'm currently thrashing about getting openSUSE 12.2 beta 2 and Fedora 17 bootloaders to acknowledge everything and I must say neither's version of GRUB2 is looking very good right now. ;-) -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

* Carlos E. R. [06-23-12 07:54]:

On 2012-06-23 06:59, Basil Chupin wrote:

...

On 23/06/12 02:33, Jim Henderson wrote:

...

As I just mentioned to Andreas, I came across this a few minutes ago:

https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html

Well, at least these people clearly know what they have to do.

Would it be a "good idea" for all of linux to embrace this *solution* and use/share the same key/loader? -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Sat, Jun 23, 2012 at 5:57 AM, Administrator wrote:

...

...

As I just mentioned to Andreas, I came across this a few minutes ago:

https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html

Well, at least these people clearly know what they have to do.

So what do we (openSUSE) need to do so we also have a decision about which path we will follow?

Can we create a (short) list of proposals and a list of decision criteria?

David

So far there are two strategies on the books: the Red Hat / Fedora strategy and the Canonical / Ubuntu strategy. Instead of further discussion, proposals, decision criteria, etc., let's make a list of peoples' names. Who will make the decision? And I don't mean "SUSE corporate", "the openSUSE team", "the lawyers", etc. I mean actual names of actual people with email addresses and phone numbers that we can hold accountable for the decision. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

...

...

...

As I just mentioned to Andreas, I came across this a few minutes ago:

https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html

Well, at least these people clearly know what they have to do.

So what do we (openSUSE) need to do so we also have a decision about which path we will follow?

Can we create a (short) list of proposals and a list of decision criteria?

David

So far there are two strategies on the books: the Red Hat / Fedora strategy and the Canonical / Ubuntu strategy. Instead of further discussion, proposals, decision criteria, etc., let's make a list of peoples' names. Who will make the decision? And I don't mean "SUSE corporate", "the openSUSE team", "the lawyers", etc. I mean actual names of actual people with email addresses and phone numbers that we can hold accountable for the decision.

Not really a "community" approach - you decide (without guidance) and we'll get upset with you (hold you accountable) if we don't like the decision. I like the decision criteria presented in the Ubuntu piece: - must be able to boot to a live CD / DVD without the need to go into BIOS settings - must be able to install without the need to go into BIOS settings - we must be able to continue community development of all parts of the distribution including kernel & boot loader - it must not require new keys (or whatever externally provided security doo-dahs) for new releases of the distribution / software package - it should allow a boot menu where people can have installed and be able to choose different installs of Linux (or O/Ss of their choice) - it must be compatible with the licences of the existing distribution packages i.e. no radical overhaul / restructuring - it should be familiar to and understandable by our community (developers and users) i.e. no extensive relearning needed Any other criteria? If we give criteria like these to a group of experts and they devise a solution which fits, then (implicitly or explicitly) we agree. David -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org