Re: [gentoo-dev] New global USE flag ps
El vie, 15-06-2012 a las 05:43 +0300, Samuli Suominen escribió: On 06/15/2012 05:02 AM, Mike Frysinger wrote: On Thursday 14 June 2012 21:16:31 Samuli Suominen wrote: So how about renaming USE=gs consumers to USE=ps and making USE=ps global flag with the proposed description? merging is a good idea. getting away from ghostscript is good. i might suggest expanding ps to postscript though as ps is a bit generic ... -mike well, I admit I was sort of trying take the shorter road (less to rename :-) so yeah, USE=postscript it shall be unless someone objects... - Samuli +1 for postscript signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ebuild laziness and binpkg overhead
El mar, 12-06-2012 a las 23:02 -0400, Mike Frysinger escribió:
i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have to
call the respective src_* func from an inherited eclass. unfortunately this
adds pointless overhead to binpkgs. can we please move away from this
practice ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
Will CC the rest of gnome team because I thought this way of passing
configure options were intentional for some reason (or, at least, I
remember being using it for a looong time)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 13:24, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 10:33, Ben de Groot yng...@gentoo.org wrote: On 15 June 2012 12:45, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. And our refusal to pay for the signing affects precisely nobody except for our users, who will have to jump through an extra hoop to make their system work. On the flip side, having a simple way to use this infrastructure means that people who care about security can get a chain of trust from the firmware to the kernel (heck, maybe even userspace one day). This is something that is worth having as well. I agree that security is a worthwhile goal. I just don't trust Microsoft. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Maybe we could get one such a blob for all distros/systems? Also, does this signature system have any restrictions on what is signed and what is not? In other words, will they actually sign a blob saying 'work-around signatures' on the top? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/13/2012 06:02 AM, Mike Frysinger wrote:
i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have to
call the respective src_* func from an inherited eclass. unfortunately this
adds pointless overhead to binpkgs. can we please move away from this
practice ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
DOCS for src_install, PATCHES for src_prepare, and XFCONF for src_configure
No way we will add all 3 phases to every Xfce ebuild since that would
defeat the purpose of the xfconf.eclass which is designed so that we
cope with 99,0% using just pkg_setup()
Using all 3 vars would also likely mean that the diff's for xfce-overlay
for ebuilds would increase to unmaintainable stage (the
ebuilds are generated from gentoo-x86, not the otherway around)
The pros overweight the cons * N
- Samuli
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 09:26, schrieb Michał Górny: On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Maybe we could get one such a blob for all distros/systems? I guess nothing prevents you from re-distributing Fedora's blob. Also, does this signature system have any restrictions on what is signed and what is not? In other words, will they actually sign a blob saying 'work-around signatures' on the top? They might sign it. I think it is just an automated process verified with smartcards. The point is, they will also blacklist it as soon as malware starts using it (or as soon as they are aware of the possibility). It should also be noted that having a bootloader blob is not enough. You have to do it like Fedora and sign the kernel and modules as well as removing kernel features that could result in security breaches (everything outlined in [1]). I don't see any reasonable way to do this while allowing users to build their own kernel and third-party modules. In the end, I think we'll need *-bin packages for everything running in kernel-space. [1] http://mjg59.dreamwidth.org/12368.html Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/15/2012 10:44 AM, Samuli Suominen wrote: Using all 3 vars would also likely mean that the diff's for xfce-overlay * vars - phases silly typing error. sorry.
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 15.06.2012 06:50, schrieb Duncan: Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. I've been following developments and wondering a bit about this myself. I had concluded that at least for x86/amd64, where MS is mandating a user controlled disable-signed-checking option, gentoo shouldn't have a problem. Other than updating the handbook to accommodate UEFI, presumably along with the grub2 stabilization, I believe we're fine as if a user can't figure out how to disable that option on their (x86/amd64) platform, they're hardly likely to be a good match for gentoo in any case. As a user, I'd still like to have the chance of using Secure Boot with Gentoo since it _really_ increases security. Even if it means I can no longer build my own kernel. ARM and etc could be more problematic since MS is mandating no-unlock there, last I read. I have no clue how they can get away with that anti- trust-wise, but anyway... But I honestly don't know enough about other than x86/amd64 platforms to worry about it, personally. I guess anti-trust is not an issue since MS is not even close to having a monopoly in ARM. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 03:12 AM, Ben de Groot wrote: On 15 June 2012 13:24, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 10:33, Ben de Groot yng...@gentoo.org wrote: On 15 June 2012 12:45, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. And our refusal to pay for the signing affects precisely nobody except for our users, who will have to jump through an extra hoop to make their system work. On the flip side, having a simple way to use this infrastructure means that people who care about security can get a chain of trust from the firmware to the kernel (heck, maybe even userspace one day). This is something that is worth having as well. I agree that security is a worthwhile goal. I just don't trust Microsoft. It's more of a pay us or your system can't boot that I'm opposed to. Saying I just don't trust Microsoft is second to I just don't trust corporations that extort money from me just so I can boot. I don't care who we are paying, I'm offended by the idea. If users can't build their own fully functional boot loader that's an issue. I'm all for the signed work-around signatures idea as it is the least objectionable... if such a thing is even possible. -Zero
Re: [gentoo-dev] UEFI secure boot and Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2012 03:49 AM, Florian Philipp wrote: Am 15.06.2012 09:26, schrieb Michał Górny: On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Maybe we could get one such a blob for all distros/systems? I guess nothing prevents you from re-distributing Fedora's blob. Also, does this signature system have any restrictions on what is signed and what is not? In other words, will they actually sign a blob saying 'work-around signatures' on the top? They might sign it. I think it is just an automated process verified with smartcards. The point is, they will also blacklist it as soon as malware starts using it (or as soon as they are aware of the possibility). It should also be noted that having a bootloader blob is not enough. You have to do it like Fedora and sign the kernel and modules as well as removing kernel features that could result in security breaches (everything outlined in [1]). I don't see any reasonable way to do this while allowing users to build their own kernel and third-party modules. In the end, I think we'll need *-bin packages for everything running in kernel-space. Being all about choice I have to agree that as long as we have both bin and normal kernels there is nothing wrong with that. However, dear god, with how many kernels we have won't this get really expensive really fast? Even just signing gentoo-sources and hardened-sources would cost a fortune considering both change weekly if not daily. So that puts us to signing just stable releases and damn users who want secure boot and a recent kernel or need a custom patch? This all seems like a huge step in the wrong direction to me, at the very least the amount of effort for this is near insurmountable in my eyes. - -Zero [1] http://mjg59.dreamwidth.org/12368.html Regards, Florian Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP2u0hAAoJEKXdFCfdEflKtPMP/3qpZ5klkvOnOfMm3anccpEm Zlo8T28+VwEjqt8m0hq/fWNteu4PbvzagD/jFLXym/OEW3w0XDFC8HI/JzbRVicT GAiv3s1zHV0yX/MzIeuSqDG+KnXJhuGige52Nxy2dyC8Ryq0kwOX90rHu2wXU8Z/ RQPuJgxf2Z34qBVNsZKHcH7caxcCUhHK+JmYwIE+hd4Y7vw1YjM49PAxLIQnhRvN lEQJt8lhyHzOzI7eScbQEtWRlGBRL/mtIoEkJa3iQb84hO9yfgAmxW512kZ4u5ZJ x8NVXaBPx6KmwdCugrryYNKMVSAUCvt08f2mPGOS2tyF3eFVcfUL3ZAzaN0Fdl+q 0nTgkq5LW0wwLB9woujuxrz949SL+g/JTH2clKZVQdwCX5w4Bt7KCeqKg6+eRhsB +9JoBZ9RYbmLQF5S+gjOuo/71Zds1IKtZIOcWp1jOdktph7udcCEvwJeQbAkK5jP rqT0jEhsTOy1RPIDBTXwLsV6/urKNCwit4nsoD+ZGHZ2GXL+OunheXJDFgfrGevD 5ownuPxa6WwLLtCd7S+6SgkcC65jamycs44IjKhoQXtsZUYOj6uBhlVIQymLFVsU r/ZeiOAilxiSP9QwTtZAohsninXQwIGxPbhwTrGp765uzalQoWzoz/Bop3IXdMgU jvY5FSvLQ9Da7RKrxC5W =XcZB -END PGP SIGNATURE-
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 10:06, schrieb Richard Farina: On 06/15/2012 03:49 AM, Florian Philipp wrote: Am 15.06.2012 09:26, schrieb Michał Górny: On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Maybe we could get one such a blob for all distros/systems? I guess nothing prevents you from re-distributing Fedora's blob. Also, does this signature system have any restrictions on what is signed and what is not? In other words, will they actually sign a blob saying 'work-around signatures' on the top? They might sign it. I think it is just an automated process verified with smartcards. The point is, they will also blacklist it as soon as malware starts using it (or as soon as they are aware of the possibility). It should also be noted that having a bootloader blob is not enough. You have to do it like Fedora and sign the kernel and modules as well as removing kernel features that could result in security breaches (everything outlined in [1]). I don't see any reasonable way to do this while allowing users to build their own kernel and third-party modules. In the end, I think we'll need *-bin packages for everything running in kernel-space. Being all about choice I have to agree that as long as we have both bin and normal kernels there is nothing wrong with that. However, dear god, with how many kernels we have won't this get really expensive really fast? Even just signing gentoo-sources and hardened-sources would cost a fortune considering both change weekly if not daily. So that puts us to signing just stable releases and damn users who want secure boot and a recent kernel or need a custom patch? This all seems like a huge step in the wrong direction to me, at the very least the amount of effort for this is near insurmountable in my eyes. -Zero [1] http://mjg59.dreamwidth.org/12368.html Regards, Florian Philipp No, it won't be expensive. Please read the link in my message on how Fedora do it: 1. You pay 99$ *once* as a registration fee. After that, you can sign as much as you want. 2. In order to avoid the hassle of the actual authentication process for signing code, Fedora simply signs a stage-1 boot loader which then verifies all further stages against a custom Fedora key. This key also has to be secure but it means they can use their own, automated tool chain for signing kernel and grub builds. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 09:58, schrieb Richard Farina: On 06/15/2012 03:12 AM, Ben de Groot wrote: On 15 June 2012 13:24, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 10:33, Ben de Groot yng...@gentoo.org wrote: On 15 June 2012 12:45, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. And our refusal to pay for the signing affects precisely nobody except for our users, who will have to jump through an extra hoop to make their system work. On the flip side, having a simple way to use this infrastructure means that people who care about security can get a chain of trust from the firmware to the kernel (heck, maybe even userspace one day). This is something that is worth having as well. I agree that security is a worthwhile goal. I just don't trust Microsoft. It's more of a pay us or your system can't boot that I'm opposed to. Saying I just don't trust Microsoft is second to I just don't trust corporations that extort money from me just so I can boot. I don't care who we are paying, I'm offended by the idea. If users can't build their own fully functional boot loader that's an issue. I'm all for the signed work-around signatures idea as it is the least objectionable... if such a thing is even possible. -Zero It is the most objectionable idea *I* can think of. Most importantly because it puts the Dev who volunteers to prove his or her identity to Verisign into a huge legal risk: Secure Boot is designed to prevent root kits. And whether you like it or not, it achieves this goal since it is a well designed system with few potential flaws. That means providing signature work-arounds which include your actual real name and other identifiable records (as they have to contain your public key) makes you an accessory to computer crimes. Besides, it wouldn't work long. They can blacklist keys. This isn't a half-arsed pseudo-secure system like DVD-CSS or WEP. We cannot break it in a 10 minute mailing list discussion. We have to play by the rules or don't play at all. Everything else will require years or decades of research. Regards, Florian Philipp Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new global useflag libass
On Fri, Jun 15, 2012 at 7:06 AM, Ben de Groot yng...@gentoo.org wrote:
Hi,
As per the discussion in bug #328245, we would like to propose a
new global useflag, to replace both ass and libass local useflags
currently in media-video/{ffmpeg,mplayer,mplayer2,vlc}.
The proposed description is the one already used in mplayer{,2}:
libass = SRT/SSA/ASS (SubRip / SubStation Alpha) subtitle support
Any comments?
One comment: amongst those three you did the best name selection for the useflag
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 12:28 AM, Greg KH gre...@gentoo.org wrote: Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. So, there are 22 posts already, so I'm going to try to cover a bunch of topics in one post. I've been thinking about this a fair bit. 1. Speaking as an individual trustee... The Gentoo Foundation legally speaks for Gentoo, can sign contracts, and can write checks. I don't really forsee any legal issues should we decide we want to pursue any kinds of relationships with MS or other entities associated with UEFI. Obviously any decision to actually pursue this would not be taken lightly. 2. From what I've heard the cost of getting a key that would be recognized by UEFI firmware is as low as a $99 one-time payment, and we pay many times that for stuff like trademark registration, corporate filing fees, not to mention hardware for infrastructure. Cost is likely a non-issue. 3. Freedom IS a big issue - my sense is that getting support from the powers that be for UEFI comes with a lot of strings. If we had a key the easiest solution would be to just write a signed GRUB stage1 that works exactly like the one we're all using, and it would load whatever you want, linux or windows or Stuxnet or otherwise. Once Malware writers start embedding our bootloader in their stuff I assume that the people issuing the keys will have the ability to revoke it (at least for new hardware). 4. Fedora is getting around #3 by making the whole thing a big trusted infrastructure - signature chains for all the kernel-space code. That meshes well with their whole /usr move initiative - you just have this big blog of stuff that you trust and never touch, and you can be sure you're running genuine RedHat goodness, just like all those iPhone users out there. :) 5. If somebody (perhaps under the umbrella of hardened) wanted to create a Gentoo project around a fully trusted Gentoo I'd be completely supportive of that. It would take work. In the spirit of Gentoo we should allow anybody to build their own signed with their own key, and perhaps we might have an official Gentoo-certified one that we would sign and the Foundation would obtain the necessary UEFI keys. However, that should be viewed as more of a service, and not a core offering - Gentoo will never depend on a piece of non-free software or metadata (and I'd probably lump a signing key into that category). The same tools (minus the private keys) used to generate any secure offering made by Gentoo should be available for users to use and sign their own systems. 6. At least on x86 users can either disable secure boot, or load their own signing keys. We should try to support both. While the full secure infrastructure of #5 will undoubtedly be a significant effort we could at least have the handbook have a section on how to sign your grub when building it and install it in a way that it can be used to boot (installing the keys themselves might be firmware-dependent, but to the extent that standards exist we can be helpful). 7. In general anybody who would be a happy Gentoo user should have no issues with signing their own bootloader, or disabling secure boot. 8. I think the bigger issue is with ARM, and I'm not personally clear on what the exact policy is there. That really strikes me as antitrust, but MS might argue that on ARM they have no monopoly (instead we have a bunch of different vendors who almost universally lock down their hardware). I can't really see how any solution that didn't give the end-user the ability to run arbitrary code on their machine could be called Gentoo so our ability to distribute signed bootloaders there is going to be limited. Maybe we create the ability to sign your own as with x86, and make the users pay the $99 for their own keys. As long as individual users don't distribute their insecure bootloaders they shouldn't be at risk of getting them revoked. Well, that's a lot, but those are my impressions. In short I see this as more of a speed-bump for x86, but a much more fundamental problem for ARM. Personally I never buy a general-purpose computing device like a PC or smartphone unless I know in advance that I can gain full control over it. Hopefully that option will remain open to me a lot longer. I'd be personally interested in pointers to info on what the powers that be do and don't allow with UEFI. I've seen lots of sky-is-falling blog entries and discussion but little in the way of specs, and more importantly, policies. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 15:58, Richard Farina sidh...@gmail.com wrote: On 06/15/2012 03:12 AM, Ben de Groot wrote: On 15 June 2012 13:24, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 10:33, Ben de Groot yng...@gentoo.org wrote: On 15 June 2012 12:45, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. And our refusal to pay for the signing affects precisely nobody except for our users, who will have to jump through an extra hoop to make their system work. On the flip side, having a simple way to use this infrastructure means that people who care about security can get a chain of trust from the firmware to the kernel (heck, maybe even userspace one day). This is something that is worth having as well. I agree that security is a worthwhile goal. I just don't trust Microsoft. It's more of a pay us or your system can't boot that I'm opposed to. That's why I called it ransom money. I'm very opposed to that too. But if we're talking about security and a chain of trust, then Microsoft has no place in that either. Saying I just don't trust Microsoft is second to I just don't trust corporations that extort money from me just so I can boot. I don't care who we are paying, I'm offended by the idea. If users can't build their own fully functional boot loader that's an issue. I'm all for the signed work-around signatures idea as it is the least objectionable... if such a thing is even possible. -Zero -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 12:14, schrieb Rich Freeman: [...] +1 for your assessment so far. I'd be personally interested in pointers to info on what the powers that be do and don't allow with UEFI. I've seen lots of sky-is-falling blog entries and discussion but little in the way of specs, and more importantly, policies. Rich Specs and user manuals can be found here: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK_II_User_Documentation More detailed specs can be found on http://www.uefi.org The UEFI Specification v. 2.3.1 contains details on Secure Boot. I wasn't able to locate any official policies or best practices. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 10:37:02AM +0200, Florian Philipp wrote Besides, it wouldn't work long. They can blacklist keys. Question... how would blacklisting work on linux machines? Let's say Joe Blow gets a signing key and then passes it around. I can see that if you want to build an executable (*.exe) to run under Windows, you'll run into problems if the monthly MS Windows Update kills that specific key. How could MS do anything to linux users who used the key to get their machine running? All I can think of is that the blacklisted keys would be added to some encrypted table in the UEFI in future versions of the UEFI/BIOS. Oh yeah, remember to *NOT* do unnecessary firmware updates to your UEFI/BIOS. As for a signed 1st-stage bootloader, is it just me, or is nobody else concerned/paranoid about MS sticking their binary code on my machine? We used to laugh at Sony rootkits, but that's what we could be looking at here. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes waltd...@waltdnes.org wrote: Question... how would blacklisting work on linux machines? Let's say Joe Blow gets a signing key and then passes it around. I can see that if you want to build an executable (*.exe) to run under Windows, you'll run into problems if the monthly MS Windows Update kills that specific key. I took the time to read the MS Hardware Certification guide. I haven't read the full UEFI spec though it is referenced to it. It sounds like UEFI has a provision for revocation, and that includes an area of flash to store revoked keys. So, if you booted the device on Windows, then Windows could download a list of keys MS doesn't like, and then since Windows is trusted by the firmware it could add those keys to the flash. Then on a reboot the firmware would no longer boot those keys in secure mode. So, the revocation is non-volatile, and doesn't require a firmware update. Of course, if you never run Windows on the device then it probably won't get the update. It wasn't 100% clear, but it sounds like a full factory reset of the firmware might clear these revoked keys out (it definitely is supposed to clear out any custom keys you load). After reading up it seems to me that the best bet for somebody who wants free as in freedom is to just run in custom mode and load their own keys. The MS document leaves a lot of policy questions unanswered though. The vendor has to trust the MS key, and has to secure their root keys. However, they can trust any number of keys, and nothing is said about those keys having to be secure. It seems like that is a loophole that would be rapidly closed in practice if a vendor got out of line. For ARM users are up the creek unless they can get the vendor to include their keys, or get a signature from somebody whose keys are included. ARM lacks the ability to use custom mode, which means you can't load your own keys, and it can't disable secure boot. Then again, all of this is only as good as the implementation. My current Android phone used just about all the tricks in the spec (flash is locked by bootloader, no downgrading, and so on). However, in the case of my phone messing with the power supply can reset the flash controller before it resets the CPU, unlocking it and allowing a rooted device to flash the bootloader. However, the UEFI specs themselves seem secure, and you can't count on every piece of hardware having an exploit. I think that anybody that really cares about security should be running in custom mode anyway, and should just re-sign anything they want to run. Custom mode lets you clear every single key in the system from the vendor on down, and gives you the ability to ensure the system only boots stuff you want it to. The MS spec does require a full factory reset to restore the original keys, though if you're using secure boot and TPM you could ensure that your hard drive becomes unreadable if this is done (unless the TPM has some backdoor and your vendor is complicit in accessing it). I don't have a problem with secure boot, and obviously to use it any pre-loaded OS has to have pre-loaded keys. What I don't like is the way certain companies are getting privileged in the process. If a full factory reset unlocked the machine, letting the first CD you boot from restore that OS vendor's keys or whatever, then then that would be more neutral. The whole bit about not allowing users to load their keys on ARM is obviously objectionable - I'm fine with ensuring security by making the user go into the pre-boot firmware, but the computer owner should have the final say. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 06:57 AM, Chí-Thanh Christopher Nguyễn wrote: Greg KH schrieb: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. For the current crop of hardware, it is probably sufficient to add a paragraph to the handbook which tells the user to disable secure boot. Getting users' self-compiled boot loaders signed with a Gentoo key is probably infeasible. If you have influence on UEFI secure boot spec, you could suggest that they mandate a UI which lists all boot images known to the EFI boot manager, and the user can easily whitelist both individual loaders and the keys used to sign them. That would be a good compromise. -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 12:14 PM, Rich Freeman wrote: 5. If somebody (perhaps under the umbrella of hardened) wanted to create a Gentoo project around a fully trusted Gentoo I'd be completely supportive of that. It would take work. In the spirit of Gentoo we should allow anybody to build their own signed with their own key, and perhaps we might have an official Gentoo-certified one that we would sign and the Foundation would obtain the necessary UEFI keys. However, that should be viewed as more of a service, and not a core offering - Gentoo will never depend on a piece of non-free software or metadata (and I'd probably lump a signing key into that category). The same tools (minus the private keys) used to generate any secure offering made by Gentoo should be available for users to use and sign their own systems. If we want to try to get serious on 5, we could try to gather the hardened/security people across distributions and setup the whole chain to be parallel and cut deals with OEM to store this trust-chain keys along with MS. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/15/2012 09:44 AM, Samuli Suominen wrote: Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, DOCS for src_install, PATCHES for src_prepare, and XFCONF for src_configure No way we will add all 3 phases to every Xfce ebuild since that would defeat the purpose of the xfconf.eclass which is designed so that we cope with 99,0% using just pkg_setup() defining a function and call it from the eclass would be impossible? lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 09:54:12AM +0200, Florian Philipp wrote I guess anti-trust is not an issue since MS is not even close to having a monopoly in ARM. Will you be able to get an ARM machine without their UEFI? If MS ever gets huge in the ARM arena, and 95% of ARM cpus go into Windows machines, how many companies will make cpus for the remaining 5%. Remember how MS strongarmed OEMs into a Windows tax? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 8:18 AM, Luca Barbato lu_z...@gentoo.org wrote: On 06/15/2012 06:57 AM, Chí-Thanh Christopher Nguyễn wrote: If you have influence on UEFI secure boot spec, you could suggest that they mandate a UI which lists all boot images known to the EFI boot manager, and the user can easily whitelist both individual loaders and the keys used to sign them. That would be a good compromise. Agreed, though MS is likely to be sensitive about how this is done. One of their requirements: System.Fundamentals.Firmware.UEFISecureBoot / 14: Mandatory. No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system. Sounds like they want to make getting around signature issues a fairly technical exercise. This of course raises the barrier to loading another OS, though to be fair the Stuxnet wants to access your boot sector - hit OK to allow or Cancel to not display the cute video your friend sent you options that are typical these days hasn't really been very effective in keeping out malware. Rich
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Fri, 15 Jun 2012 14:24:54 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 06/15/2012 09:44 AM, Samuli Suominen wrote: Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, DOCS for src_install, PATCHES for src_prepare, and XFCONF for src_configure No way we will add all 3 phases to every Xfce ebuild since that would defeat the purpose of the xfconf.eclass which is designed so that we cope with 99,0% using just pkg_setup() defining a function and call it from the eclass would be impossible? Sounds like quite a good solution. We may also consider defining src_setup() in new EAPI. Of course, still going this way we'll end up with src_phase00(), src_phase40() and so on... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 8:22 AM, Luca Barbato lu_z...@gentoo.org wrote: If we want to try to get serious on 5, we could try to gather the hardened/security people across distributions and setup the whole chain to be parallel and cut deals with OEM to store this trust-chain keys along with MS. Perhaps. Since we're only talking about the kernel really and that doesn't vary as much across distros, we might even be able to get momentum for it. You could create a standard secure kernel - probably as a patch set initially but perhaps merged into mainline with a config option that turns on key verification for loading modules. Anybody could use that to secure their own systems by using their own key in the configuration. The central body could prepare and sign binaries for individual distros. A distro would supply a kernel config file and patch set and identifier for the upstream kernel to build against. The central body would audit the patches and config for security, build the kernel, and sign it, assessing a fee perhaps (likely cheap for config-only, and expensive for extensive patches). The costs need not be all that high - if you assume that vanilla linux with the config option turned on is good enough then you only have to check that the option is set, blacklist bad settings, and verify patches. They could revoke certs when security issues are found, by keeping a history of what configs/versions got signed. Users could load the signing key of this body into their custom settings, or OEMs could be persuaded to include it. The latter would never be 100% effective unless a court ordered it. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 14:01, schrieb Rich Freeman: On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes waltd...@waltdnes.org wrote: Question... how would blacklisting work on linux machines? Let's say Joe Blow gets a signing key and then passes it around. I can see that if you want to build an executable (*.exe) to run under Windows, you'll run into problems if the monthly MS Windows Update kills that specific key. I took the time to read the MS Hardware Certification guide. I haven't read the full UEFI spec though it is referenced to it. It sounds like UEFI has a provision for revocation, and that includes an area of flash to store revoked keys. So, if you booted the device on Windows, then Windows could download a list of keys MS doesn't like, and then since Windows is trusted by the firmware it could add those keys to the flash. Then on a reboot the firmware would no longer boot those keys in secure mode. So, the revocation is non-volatile, and doesn't require a firmware update. Besides, even if there was no update mechanism, it wouldn't help us. Even if our key was only blacklisted in the next generation of mainboards, what would we have gained? We cannot purposefully break the system every time a new mainboard is released. Of course, if you never run Windows on the device then it probably won't get the update. From skimming the UEFI specs it sounds like there are similar tools for Linux under development. It wasn't 100% clear, but it sounds like a full factory reset of the firmware might clear these revoked keys out (it definitely is supposed to clear out any custom keys you load). After reading up it seems to me that the best bet for somebody who wants free as in freedom is to just run in custom mode and load their own keys. The MS document leaves a lot of policy questions unanswered though. The vendor has to trust the MS key, and has to secure their root keys. However, they can trust any number of keys, and nothing is said about those keys having to be secure. It seems like that is a loophole that would be rapidly closed in practice if a vendor got out of line. For ARM users are up the creek unless they can get the vendor to include their keys, or get a signature from somebody whose keys are included. ARM lacks the ability to use custom mode, which means you can't load your own keys, and it can't disable secure boot. Then again, all of this is only as good as the implementation. My current Android phone used just about all the tricks in the spec (flash is locked by bootloader, no downgrading, and so on). However, in the case of my phone messing with the power supply can reset the flash controller before it resets the CPU, unlocking it and allowing a rooted device to flash the bootloader. However, the UEFI specs themselves seem secure, and you can't count on every piece of hardware having an exploit. I think that anybody that really cares about security should be running in custom mode anyway, and should just re-sign anything they want to run. Custom mode lets you clear every single key in the system from the vendor on down, and gives you the ability to ensure the system only boots stuff you want it to. The MS spec does require a full factory reset to restore the original keys, though if you're using secure boot and TPM you could ensure that your hard drive becomes unreadable if this is done (unless the TPM has some backdoor and your vendor is complicit in accessing it). I don't have a problem with secure boot, and obviously to use it any pre-loaded OS has to have pre-loaded keys. What I don't like is the way certain companies are getting privileged in the process. If a full factory reset unlocked the machine, letting the first CD you boot from restore that OS vendor's keys or whatever, then then that would be more neutral. The whole bit about not allowing users to load their keys on ARM is obviously objectionable - I'm fine with ensuring security by making the user go into the pre-boot firmware, but the computer owner should have the final say. Yeah, the ARM policy is a pretty obvious don't root the phone attempt. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 15.06.2012 14:28, schrieb Walter Dnes: On Fri, Jun 15, 2012 at 09:54:12AM +0200, Florian Philipp wrote I guess anti-trust is not an issue since MS is not even close to having a monopoly in ARM. Will you be able to get an ARM machine without their UEFI? If MS ever gets huge in the ARM arena, and 95% of ARM cpus go into Windows machines, how many companies will make cpus for the remaining 5%. Remember how MS strongarmed OEMs into a Windows tax? When MS gets a strong hold in ARM, they will have to face the same antitrust measures they face on x86 and their policy will likely have to change. I don't say its a nice outlook. The whole antitrust system is reactive and takes years to have any effect. But until then (if it ever happens)? Support other big players in ARM, don't buy Nokia/Windows phones, hope for the best. The usual ... Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: esethome
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/06/12 04:51 PM, Mike Frysinger wrote:
On Wednesday 13 June 2012 15:35:40 Ian Stakenvicius wrote:
--- user.eclass [some timestamp] +++
user.eclass.esethome [some other timestamp] @@ -388,3 +388,63
@@ }
fi + +# @FUNCTION: esethome
has to be inside the giant if block. so put this above the fi.
+# @USAGE: user homedir +# @DESCRIPTION: +# Update the home
directory in a platform-agnostic way. +# Required parameters is
the username and the new home directory. +# Specify -1 if you
want to set home to the enewuser default +# of /dev/null. +# If
the new home directory does not exist, it is created. +# Any
previously existing home directory is NOT moved. +esethome() { +
_assert_pkg_ebuild_phase ${FUNCNAME} + + # get the
username + local euser=$1; shift + if [[ -z ${euser}
]] ; then + eerror No username specified ! +
die Cannot call esethome without a username + fi + +
# lets see if the username already exists + if [[ ! -n
$(egetent passwd ${euser}) ]] ; then
! -n - -z -mike
So outside of syntax issues like above, anyone have any issues with my
adding this to user.eclass ?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iF4EAREIAAYFAk/bNaoACgkQ2ugaI38ACPAFRgEApwLkrsqSIW0nVK4l/dUTRzV9
ijEnbfa+BLc1skwfW4QA+gKgpmsz/K5VqXnVWyXocGqO98RYJL8lL3qm7k0Hs6uZ
=9i38
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: VOICEMAIL_STORAGE as a USE_EXPAND for net-misc/asterisk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/06/12 06:30 PM, Tony Chainsaw Vroon wrote: Good evening, As per bug #421037, there is a demand to make multiple voicemail storage backends switchable within the ebuild. The USE_EXPAND mechanism would automatically provide an explanation of the selections being made (as opposed to overloading USE=odbc in what seems to me a non-obvious way). The dev manual suggests this is presented for discussion, so here we are. Thoughts? Regards, Tony V. I haven't used asterisk for a long time, but this makes a lot of sense to me. +1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/bNmcACgkQ2ugaI38ACPDbUAD/XoQ0aQDp8NSFidzlP69ImpqA X8D1UvMJrvxPOf8wUOEBALTaKaeo5eT27XPTtZE4MUHHDJnrsyHMraVC/dYlQuoM =Hn8k -END PGP SIGNATURE-
Re: [gentoo-dev] New global USE flag gs (app-text/ghostscript-gpl)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/06/12 07:58 PM, Peter Stuge wrote: Samuli Suominen wrote: 9'ish consumers. I propose Enable support for the PostScript language Perhaps ps or postscript instead of the implementation-centric gs ? //Peter I think based on the consumers described we should keep the flag as 'gs' as this is primarily for ghostscript-based support and not generic postscript capability. That said, there's only nine of them, and as I can't see that many more packages suddenly including support for ghostscript I don't see that much of a need in making this flag be global...? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/bOAYACgkQ2ugaI38ACPC9OwD/W0ofi+chYYZ+k5ABo+VfODHs F/83jl30ru+iOakp/nkA/Rg+8H6wrNyR/1BAe78T2UfhgMEtGOQy16TA+UrmPrO6 =YpRu -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: esethome
Mike Frysinger wrote:
+ # lets see if the username already exists
+ if [[ ! -n $(egetent passwd ${euser}) ]] ; then
! -n - -z
Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?
//Peter
pgp9d1zHonyTA.pgp
Description: PGP signature
Re: [gentoo-dev] New global USE flag ps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/06/12 10:43 PM, Samuli Suominen wrote: On 06/15/2012 05:02 AM, Mike Frysinger wrote: On Thursday 14 June 2012 21:16:31 Samuli Suominen wrote: So how about renaming USE=gs consumers to USE=ps and making USE=ps global flag with the proposed description? merging is a good idea. getting away from ghostscript is good. i might suggest expanding ps to postscript though as ps is a bit generic ... -mike well, I admit I was sort of trying take the shorter road (less to rename :-) so yeah, USE=postscript it shall be unless someone objects... - Samuli This makes sense globally, +1 As mentioned some packages (graphviz comes to mind also) will need to keep 'gs' locally since it is used as a ghostscript-specific flag. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/bOMgACgkQ2ugaI38ACPBkmgD/W05LR/3OmEFmzba/x0YLjsP+ 6UUzcPwxRbJ3ArjIza0A/1XgPGoecSrrqAKhLi2SiqyqpwolOw3MP+ol1Oa85/DP =iQRE -END PGP SIGNATURE-
[gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
It is a little confusing when the function reports .a removal when no
such file exists. Also, explain why the file is removed.
---
eclass/eutils.eclass |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 116f7bc..931d97d 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -1438,8 +1438,10 @@ prune_libtool_files() {
# Remove static libs we're not supposed to link against.
if grep -q '^shouldnotlink=yes$' ${f}; then
- einfo Removing unnecessary ${archivefile#${D%/}}
- rm -f ${archivefile}
+ if [[ -f ${archivefile} ]]; then
+ einfo Removing unnecessary
${archivefile#${D%/}} (static plugin)
+ rm -f ${archivefile}
+ fi
# The .la file may be used by a module loader, so avoid
removing it
# unless explicitly requested.
--
1.7.10.2
Re: [gentoo-dev] RFC: esethome
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/06/12 09:27 AM, Peter Stuge wrote:
Mike Frysinger wrote:
+ # lets see if the username already exists + if [[
! -n $(egetent passwd ${euser}) ]] ; then
! -n - -z
Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?
//Peter
Ever? Yes, but only if what is being returned can contain spaces (and
this matters in the way that it's used). In the case of 'egetent
passwd', afaict no as it doesn't return anything with whitespace in it.
Examples -- this works:
$ bubba=test thing ; if [ -n $(echo $bubba) ]; then echo OK; fi
OK
Example -- this fails:
$ bubba=test thing ; if [ -n $(echo $bubba) ]; then echo OK; fi
bash: [: test: binary operator expected
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iF4EAREIAAYFAk/bOioACgkQ2ugaI38ACPAUegD+JPzG4oX25QcqXYSfp/c2IE5o
aydKUHZonedILskm5UoA/2bnn2PMFh5lm1rXh7H4/2d9MQaghAUlCmMv0/XORQtW
=7fD+
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: esethome
On 15-06-2012 09:35:38 -0400, Ian Stakenvicius wrote:
On 15/06/12 09:27 AM, Peter Stuge wrote:
Mike Frysinger wrote:
+ # lets see if the username already exists + if [[
! -n $(egetent passwd ${euser}) ]] ; then
! -n - -z
Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?
Ever? Yes, but only if what is being returned can contain spaces (and
this matters in the way that it's used). In the case of 'egetent
passwd', afaict no as it doesn't return anything with whitespace in it.
Examples -- this works:
$ bubba=test thing ; if [ -n $(echo $bubba) ]; then echo OK; fi
OK
Example -- this fails:
$ bubba=test thing ; if [ -n $(echo $bubba) ]; then echo OK; fi
bash: [: test: binary operator expected
Yes, but this works:
$ bubba=test thing ; if [[ -n $(echo $bubba) ]]; then echo OK; fi
OK
(and he's using [[, not [)
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] RFC: esethome
Ian Stakenvicius wrote:
Mike Frysinger wrote:
+ # lets see if the username already exists + if [[
! -n $(egetent passwd ${euser}) ]] ; then
! -n - -z
Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?
Ever? Yes, but only if what is being returned can contain spaces
Sorry, I should have mentioned that I had the case of the empty
string in mind.
//Peter
Re: [gentoo-dev] RFC: esethome
On 15-06-2012 15:41:03 +0200, Peter Stuge wrote:
Ian Stakenvicius wrote:
Mike Frysinger wrote:
+ # lets see if the username already exists + if [[
! -n $(egetent passwd ${euser}) ]] ; then
! -n - -z
Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?
Ever? Yes, but only if what is being returned can contain spaces
Sorry, I should have mentioned that I had the case of the empty
string in mind.
Here for the same reason, the difference between [[ and [ is essential.
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] RFC: esethome
Fabian Groffen wrote:
+ if [[ ! -n $(egetent passwd ${euser}) ]] ; then
! -n - -z
Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?
Ever? Yes, but only if what is being returned can contain spaces
Sorry, I should have mentioned that I had the case of the empty
string in mind.
Here for the same reason, the difference between [[ and [ is essential.
It's not clear to me why?
[] is shorthand for test. Both test and [[]] in my man bash read:
--8--
Expressions are composed of the primaries described .. under
CONDITIONAL EXPRESSIONS.
--8--
There it says:
--8--
Conditional expressions are used by the [[ compound command and
the test and [ builtin commands
--8--
and:
--8--
-z string
True if the length of string is zero.
string
-n string
True if the length of string is non-zero.
--8--
..which does not at all make it clear that the string is actually
optional?
Under Command Substitution it says:
--8--
Embedded newlines are not deleted, but they may be removed during
word splitting.
..
If the substitution appears within double quotes, word splitting
and pathname expansion are not performed on the results.
--8--
..confirming that there is some processing of the substitution.
I also did the tests before asking the question. I'm not trying to
say that the code doesn't work on my system. I'm asking if it will
work the same on every version of bash, in spite of what seems to
be a conflict between real world and documentation.
//Peter
pgp22DokPyk82.pgp
Description: PGP signature
Re: [gentoo-dev] RFC: esethome
On Fri, Jun 15, 2012 at 10:05 AM, Peter Stuge pe...@stuge.se wrote:
Fabian Groffen wrote:
+ if [[ ! -n $(egetent passwd ${euser}) ]] ; then
! -n - -z
Does the $() argument ever need to be double quoted, or do all
versions of bash actually have the string argument optional even
though that's not what the man page reads?
Ever? Yes, but only if what is being returned can contain spaces
Sorry, I should have mentioned that I had the case of the empty
string in mind.
Here for the same reason, the difference between [[ and [ is essential.
It's not clear to me why?
[] is shorthand for test. Both test and [[]] in my man bash read:
--8--
Expressions are composed of the primaries described .. under
CONDITIONAL EXPRESSIONS.
--8--
There it says:
--8--
Conditional expressions are used by the [[ compound command and
the test and [ builtin commands
--8--
and:
--8--
-z string
True if the length of string is zero.
string
-n string
True if the length of string is non-zero.
--8--
..which does not at all make it clear that the string is actually
optional?
Under Command Substitution it says:
--8--
Embedded newlines are not deleted, but they may be removed during
word splitting.
..
If the substitution appears within double quotes, word splitting
and pathname expansion are not performed on the results.
--8--
..confirming that there is some processing of the substitution.
I also did the tests before asking the question. I'm not trying to
say that the code doesn't work on my system. I'm asking if it will
work the same on every version of bash, in spite of what seems to
be a conflict between real world and documentation.
//Peter
Word splitting does not occur within double brackets. This is
documented in the bash manual.
http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs
This causes empty output from a command substitution within double
brackets to be treated as a zero-length string.
Re: [gentoo-dev] RFC: esethome
Mike Gilbert wrote: [] is shorthand for test. Both test and [[]] in my man bash read: --8-- Expressions are composed of the primaries described .. under CONDITIONAL EXPRESSIONS. --8-- And the next sentence is exactly what you wrote. :) Word splitting and pathname expansion are not performed on the words between the [[ and ]] Word splitting does not occur within double brackets. This is documented in the bash manual. http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs This causes empty output from a command substitution within double brackets to be treated as a zero-length string. Thanks for pointing me to the right place! //Peter
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Friday 15 June 2012 03:44:14 Samuli Suominen wrote: On 06/13/2012 06:02 AM, Mike Frysinger wrote: i've noticed a growing trend where people put setup of variables into pkg_setup that only matter to src_* funcs presumably so they don't have to call the respective src_* func from an inherited eclass. unfortunately this adds pointless overhead to binpkgs. can we please move away from this practice ? Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, DOCS for src_install, PATCHES for src_prepare these are static variables, so defining them in a func is pointless and XFCONF for src_configure now you're down to one variable which means you've got one func to /properly/ define -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
On 06/15/12 09:32, Michał Górny wrote:
It is a little confusing when the function reports .a removal when no
such file exists. Also, explain why the file is removed.
Why keep the -f?
---
eclass/eutils.eclass |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 116f7bc..931d97d 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -1438,8 +1438,10 @@ prune_libtool_files() {
# Remove static libs we're not supposed to link against.
if grep -q '^shouldnotlink=yes$' ${f}; then
- einfo Removing unnecessary ${archivefile#${D%/}}
- rm -f ${archivefile}
+ if [[ -f ${archivefile} ]]; then
+ einfo Removing unnecessary
${archivefile#${D%/}} (static plugin)
+ rm -f ${archivefile}
+ fi
# The .la file may be used by a module loader, so avoid
removing it
# unless explicitly requested.
Re: [gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
On Friday 15 June 2012 09:32:18 Michał Górny wrote:
# Remove static libs we're not supposed to link against.
if grep -q '^shouldnotlink=yes$' ${f}; then
- einfo Removing unnecessary ${archivefile#${D%/}}
- rm -f ${archivefile}
+ if [[ -f ${archivefile} ]]; then
+ einfo Removing unnecessary
${archivefile#${D%/}} (static
plugin)
+ rm -f ${archivefile}
+ fi
highly unlikely, but this would skip symlinks that are broken in $D, but valid
once merged into $ROOT
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 06:14 AM, Rich Freeman wrote: 8. I think the bigger issue is with ARM, and I'm not personally clear on what the exact policy is there. That really strikes me as antitrust, but MS might argue that on ARM they have no monopoly (instead we have a bunch of different vendors who almost universally lock down their hardware). This requirement by M$ is applied to hardware that wants the Certified for Windows 8 logo. If the OEMs don't care about windows 8 certification, they can provide for UEIF secure boot disabling. Since it is a voluntary acceptance in return for granting a consumer-fooling certification, they get away with an anti-competetive practice. They want to keep android off hardware used for Windows 8. Always follow the money. -- G.Wolfe Woodbury
Re: [gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
On Fri, 15 Jun 2012 11:11:58 -0400
Mike Frysinger vap...@gentoo.org wrote:
On Friday 15 June 2012 09:32:18 Michał Górny wrote:
# Remove static libs we're not supposed to link
against. if grep -q '^shouldnotlink=yes$' ${f}; then
- einfo Removing unnecessary
${archivefile#${D%/}}
- rm -f ${archivefile}
+ if [[ -f ${archivefile} ]]; then
+ einfo Removing unnecessary
${archivefile#${D%/}} (static
plugin)
+ rm -f ${archivefile}
+ fi
highly unlikely, but this would skip symlinks that are broken in $D,
but valid once merged into $ROOT
Are you suggesting || -L? Not that I see a case where
an external-symlink .a is installed alongside local .la file...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
On Fri, 15 Jun 2012 11:11:44 -0400 Michael Orlitzky mich...@orlitzky.com wrote: On 06/15/12 09:32, Michał Górny wrote: It is a little confusing when the function reports .a removal when no such file exists. Also, explain why the file is removed. Why keep the -f? For rm? -f, --force ignore nonexistent files and arguments, never prompt The second part is still valid. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
El vie, 15-06-2012 a las 09:03 +0200, Pacho Ramos escribió:
El mar, 12-06-2012 a las 23:02 -0400, Mike Frysinger escribió:
i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have to
call the respective src_* func from an inherited eclass. unfortunately
this
adds pointless overhead to binpkgs. can we please move away from this
practice ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
Will CC the rest of gnome team because I thought this way of passing
configure options were intentional for some reason (or, at least, I
remember being using it for a looong time)
I forgot to CC :S
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
On Friday 15 June 2012 12:52:56 Michał Górny wrote:
On Fri, 15 Jun 2012 11:11:58 -0400 wrote:
On Friday 15 June 2012 09:32:18 Michał Górny wrote:
# Remove static libs we're not supposed to link
against. if grep -q '^shouldnotlink=yes$' ${f}; then
- einfo Removing unnecessary
${archivefile#${D%/}}
- rm -f ${archivefile}
+ if [[ -f ${archivefile} ]]; then
+ einfo Removing unnecessary
${archivefile#${D%/}} (static
plugin)
+ rm -f ${archivefile}
+ fi
highly unlikely, but this would skip symlinks that are broken in $D,
but valid once merged into $ROOT
Are you suggesting || -L?
if you want to be pessimistic that someday this might happen, then yeah. or
just leave it and wait for someone to complain.
Not that I see a case where an external-symlink .a is installed alongside
local .la file...
true. probably not common (or even uncommon), but not impossible.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
On Friday 15 June 2012 12:54:16 Michał Górny wrote: On Fri, 15 Jun 2012 11:11:44 -0400 Michael Orlitzky wrote: On 06/15/12 09:32, Michał Górny wrote: It is a little confusing when the function reports .a removal when no such file exists. Also, explain why the file is removed. Why keep the -f? For rm? -f, --force ignore nonexistent files and arguments, never prompt The second part is still valid. i think his point was that since you just did a [[ -f ]] test, there shouldn't really be any cases where the rm would fail, so you could change the `rm -f` to `rm || die` ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 12:24 AM, Arun Raghavan wrote: On 15 June 2012 10:26, Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Although all BIOSes will have the option to turn secure boot off, I think it is something that we might not want to require for Gentoo to work properly on those machines. Also, some people might really want to sign their own bootloader and kernel, and kernel modules (myself included), so just getting that basic infrastructure in place is going to take some work, no matter who ends up signing the first-stage bootloader blob. I hadn't thought of that. I imagine the hardened team might be interested in making such infrastructure easily available as well. Oh, and on the first-stage bootloader front, I already know of 2 simple, and open source, examples that will work for Linux, so getting something like that signed might not be very tough. It's the where does the chain-of-trust stop question that gets tricky... For validating the chain of trust, it might be useful to make it possible for anyone to generate the same bootloader and verify the hashes themselves. For the truly paranoid maybe a signed stage3 + portage snapshot to generate the bootloader image from scratch. Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. Sounds like something the Gentoo Foundation could do. Can they do that? I haven't been paying attention to if we are really a legal entity still or not, sorry. I believe so, but quantumsummers is likely the best person to confirm. I've already taken a look at some of this, I think our best bet is to figure out how to use efi_stub and simply sign the kernel itself (since it can run directly from uefi now). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/14/2012 11:45 PM, Greg KH wrote: On Thu, Jun 14, 2012 at 09:28:10PM -0700, Greg KH wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. Oh, and for those that don't know, I did a lot of UEFI secure boot work in the past at SUSE, and should be soon a member of the UEFI organization through my work at the Linux Foundation, so I do have a basic grasp of the issues involved, and have a chance to get changes made, if needed, and possible, to the spec itself. greg k-h One of these days I'd like to pick your brain about some hardened UEFI interactions I've seen (with pipacs watching). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: On Fri, Jun 15, 2012 at 12:28 AM, Greg KH gre...@gentoo.org wrote: Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. So, there are 22 posts already, so I'm going to try to cover a bunch of topics in one post. I've been thinking about this a fair bit. 1. Speaking as an individual trustee... The Gentoo Foundation legally speaks for Gentoo, can sign contracts, and can write checks. I don't really forsee any legal issues should we decide we want to pursue any kinds of relationships with MS or other entities associated with UEFI. Obviously any decision to actually pursue this would not be taken lightly. Great to know that this could work, if needed. 2. From what I've heard the cost of getting a key that would be recognized by UEFI firmware is as low as a $99 one-time payment, and we pay many times that for stuff like trademark registration, corporate filing fees, not to mention hardware for infrastructure. Cost is likely a non-issue. Yes, it's cheap. 3. Freedom IS a big issue - my sense is that getting support from the powers that be for UEFI comes with a lot of strings. If we had a key the easiest solution would be to just write a signed GRUB stage1 that works exactly like the one we're all using, and it would load whatever you want, linux or windows or Stuxnet or otherwise. Once Malware writers start embedding our bootloader in their stuff I assume that the people issuing the keys will have the ability to revoke it (at least for new hardware). Yes, we need to provide some way to secure our key, which might prove impossible and foolish for Gentoo to even attempt, as it really wouldn't work out for us. 4. Fedora is getting around #3 by making the whole thing a big trusted infrastructure - signature chains for all the kernel-space code. That meshes well with their whole /usr move initiative - you just have this big blog of stuff that you trust and never touch, and you can be sure you're running genuine RedHat goodness, just like all those iPhone users out there. :) The whole chain-of-trust is an interesting issue as the UEFI spec does not require it at all, and some people on the UEFI committee have told me that it is not required either. But, others have. Getting to the root of this problem is something I'm trying to do, as it's a very important one for anyone who is going to be trusting, and providing, a key in the BIOS. 5. If somebody (perhaps under the umbrella of hardened) wanted to create a Gentoo project around a fully trusted Gentoo I'd be completely supportive of that. It would take work. In the spirit of Gentoo we should allow anybody to build their own signed with their own key, and perhaps we might have an official Gentoo-certified one that we would sign and the Foundation would obtain the necessary UEFI keys. However, that should be viewed as more of a service, and not a core offering - Gentoo will never depend on a piece of non-free software or metadata (and I'd probably lump a signing key into that category). The same tools (minus the private keys) used to generate any secure offering made by Gentoo should be available for users to use and sign their own systems. That would mean we would be in the business of creating binary packages, which is a big change from what we have been doing all of these years, and not to be taken lightly. 6. At least on x86 users can either disable secure boot, or load their own signing keys. We should try to support both. Yes. While the full secure infrastructure of #5 will undoubtedly be a significant effort we could at least have the handbook have a section on how to sign your grub when building it and install it in a way that it can be used to boot (installing the keys themselves might be firmware-dependent, but to the extent that standards exist we can be helpful). Yes. 7. In general anybody who would be a happy Gentoo user should have no issues with signing their own bootloader, or disabling secure boot. We have not seen how most BIOSes will allow this to happen, so I can't agree with this statement just yet. 8. I think the bigger issue is with ARM, and I'm not personally clear on what the exact policy is there. That really strikes me as antitrust, but MS might argue that on ARM they have no monopoly (instead we have a bunch of different vendors who almost universally lock down their hardware). I can't really see how any solution that didn't give the end-user the ability to run arbitrary code on their machine could be called Gentoo so our ability to distribute signed bootloaders there is going to be limited. Maybe we create the ability to sign your own
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 06:57:06AM +0200, Chí-Thanh Christopher Nguyễn wrote: If you have influence on UEFI secure boot spec, you could suggest that they mandate a UI which lists all boot images known to the EFI boot manager, and the user can easily whitelist both individual loaders and the keys used to sign them. That has already been attempted, and it failed, so it will not happen, sorry. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 09:49:01AM +0200, Florian Philipp wrote: Am 15.06.2012 09:26, schrieb Michał Górny: On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Maybe we could get one such a blob for all distros/systems? I guess nothing prevents you from re-distributing Fedora's blob. Fedora's blob will not boot your unsigned-with-fedoras-key kernel, so redistributing it will not help anyone :( greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 04:35:28PM -0500, Matthew Thode wrote: One of these days I'd like to pick your brain about some hardened UEFI interactions I've seen (with pipacs watching). Sure, be glad to talk about this anytime.
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 01:48:05AM -0400, Philip Webb wrote: 120614 Greg KH wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo or not worry about Gentoo right now and just focus on the other issues? Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side. I did a lot of UEFI secure boot work in the past at SUSE and should be soon a member of the UEFI organization through my work at the Linux Foundation, so I do have a basic grasp of the issues involved and have a chance to get changes made, if needed and possible, to the spec itself. Does this affect those of us who build our own machines ? Yes, it will be on your new motherboard in a matter of months. Is there likely to be any Gentoo user who is reluctant to change the default BIOS setting ? Probably lots. How can UEFI be required for Arm without running into anti-trust ? Different countries have different rules here. How far is this basically a problem for those in the USA, the rest of us having a different attitude to security issues ? Everyone in all countries are going to have to deal with this, as all motherboard manufacturers are going to be supporting this by the end of this year at the latest, due to the Windows 8 requirements. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 01:03:24PM +0800, Ben de Groot wrote: On 15 June 2012 12:45, Arun Raghavan ford_pref...@gentoo.org wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. Sorry, it's really Verisign, although I imagine you still feel the same :)
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 09:26:07AM +0200, Michał Górny wrote: On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? I think it at least makes sense to talk about it, and work out what we can and cannot do. I guess we're in an especially bad position since everybody builds their own bootloader. Is there /any/ viable solution that allows people to continue doing this short of distributing a first-stage bootloader blob? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Maybe we could get one such a blob for all distros/systems? Also, does this signature system have any restrictions on what is signed and what is not? In other words, will they actually sign a blob saying 'work-around signatures' on the top? It is uncertian at the moment what the requirements are, I'm trying to nail this down. But, in order to protect all other companies, I imagine they are going to be pretty restrictive, otherwise it really makes no sense at all to have this in the first place. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 7:55 PM, Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: The whole chain-of-trust is an interesting issue as the UEFI spec does not require it at all, and some people on the UEFI committee have told me that it is not required either. But, others have. Getting to the root of this problem is something I'm trying to do, as it's a very important one for anyone who is going to be trusting, and providing, a key in the BIOS. It sounds like the UEFI committee isn't really the problem here. You can have a UEFI firmware as long as it follows the spec. However, you won't get the Windows logo certification if you don't follow the Windows rules. I would think they'd basically want a chain of trust for anything that loads into kernel space. Otherwise all a malware author has to do is ship a signed linux kernel, have it boot a bash script that loads their malware via an unsigned kernel module, and then at that point they just intercept whatever they want to and then boot Windows, discarding the rest of the linux kernel. However, even the MS requirements say that an OEM can have other keys as well, and nothing says that all of them need to be secure (other than the root key). If I published a keypair on the internet and persuaded OEMs to include it as trusted, then in theory that would pass the MS requirements as they are currently written, and would render secure boot meaningless. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
120615 Greg KH wrote: On Fri, Jun 15, 2012 at 01:48:05AM -0400, Philip Webb wrote: Does this affect those of us who build our own machines ? Yes, it will be on your new motherboard in a matter of months. I am going to build a new machine some time in the next 12 mth , but it looks as if all I will have to do is reset the BIOS , which I'm likely to have to do for other features in any case. Is there likely to be any Gentoo user who is reluctant to change the default BIOS setting ? Probably lots. That surprises me, but we'll find out. How can UEFI be required for Arm without running into anti-trust ? Different countries have different rules here. Discussion + news items in the press do suggest that it's not anti-trust as long as it's not benefitting 1 company. Anyway, I'm not likely to be using ARM, let alone jailbreaking it. How far is this basically a problem for those in the USA, the rest of us having a different attitude to security issues ? Everyone in all countries are going to have to deal with this, as all motherboard manufacturers are going to be supporting this by the end of 2012 at the latest, due to the Windows 8 requirements. As with other similar issues in the past, we can expect the EU antitrust people to take a close look at it they may start demanding that computers are easily unlockable, if not actually required to be sold with UEFI disabled by default. Despite current scare stories out of London New York, the EU is by no means finished as a political entity no-one in USA should assume the EU will follow their lead or even that Canada will, despite our current Conservative government. I see a need for careful thought at Gentoo, but no need for panic. Thanks for your horse's mouth (smile). -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 08:41:47PM -0400, Rich Freeman wrote: On Fri, Jun 15, 2012 at 7:55 PM, Greg KH gre...@gentoo.org wrote: On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: The whole chain-of-trust is an interesting issue as the UEFI spec does not require it at all, and some people on the UEFI committee have told me that it is not required either. But, others have. Getting to the root of this problem is something I'm trying to do, as it's a very important one for anyone who is going to be trusting, and providing, a key in the BIOS. It sounds like the UEFI committee isn't really the problem here. You can have a UEFI firmware as long as it follows the spec. However, you won't get the Windows logo certification if you don't follow the Windows rules. That is exactly the case. I would think they'd basically want a chain of trust for anything that loads into kernel space. Otherwise all a malware author has to do is ship a signed linux kernel, have it boot a bash script that loads their malware via an unsigned kernel module, and then at that point they just intercept whatever they want to and then boot Windows, discarding the rest of the linux kernel. Yes, that is the problem we are facing. However, even the MS requirements say that an OEM can have other keys as well, and nothing says that all of them need to be secure (other than the root key). If I published a keypair on the internet and persuaded OEMs to include it as trusted, then in theory that would pass the MS requirements as they are currently written, and would render secure boot meaningless. The liability requirements for an OEM to accept a key into their BIOS, that is something other than Microsoft's key (if there is even the room, some bioses will not have extra room for lots of keys), is beyond anything that any Linux company can afford, or is willing to accept. greg k-h
