From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SfOgp-0002T7-Pe for garchives@archives.gentoo.org; Fri, 15 Jun 2012 05:03:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A1B86E076F; Fri, 15 Jun 2012 05:03:01 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by pigeon.gentoo.org (Postfix) with ESMTP id D6488E073F for ; Fri, 15 Jun 2012 05:02:17 +0000 (UTC) Received: by vcbf1 with SMTP id f1so1647007vcb.40 for ; Thu, 14 Jun 2012 22:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=njAIZ2+WZcqfLuicbYio8iSnBUnL0N3n2PEVOUc+kNM=; b=GXsNtPJE5+6sLKQmXpH/E7O7vt06SHwJI4130RInbiejfg86/SlDxKR9EfGMUQ+6wl b4V3vgZfKySxXTcZnZ2V0eU0FTci27MuWFMcCakx4XrktSDJZZTQFztq5o0SAyIu35VM VTS6Fpfr2soj1BGZka08Uwi4gUE5V1DyC7Cr9XcBkdNbPTsRdK5yJFRnHNl+YiQcz0+f RLdtE/k6lL81ui8JuVyjjpnVKCHeS83ECiJrMpDCZqQq8rT4dkXzlldVZBBt4rqdCP/v JHa/Ni8NI5jYSfP5uXzQOl8ieFZUwUCem4ASu3HRf0Uc3WBYfT/QtTK3J6GQFAdrH9Vi rAHQ== Received: by 10.52.94.147 with SMTP id dc19mr1994174vdb.74.1339736537348; Thu, 14 Jun 2012 22:02:17 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.171.228 with HTTP; Thu, 14 Jun 2012 22:01:57 -0700 (PDT) In-Reply-To: References: <20120615042810.GA9480@kroah.com> From: Matthew Finkel Date: Fri, 15 Jun 2012 01:01:57 -0400 Message-ID: Subject: Re: [gentoo-dev] Re: UEFI secure boot and Gentoo To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=bcaec501646766baf504c27bb8e8 X-Archives-Salt: 22aab4ee-1f3a-4e76-abaf-029413691fea X-Archives-Hash: cf2d5b2a98ae990c346de497467d6c16 --bcaec501646766baf504c27bb8e8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 15, 2012 at 12:50 AM, Duncan <1i5t5.duncan@cox.net> wrote: > 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. > > 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. > For the short term, we don't have many options beside either adding to the documentation that the User needs to disable UEFI or wipe the current valid keys and adding their own (Devs may need to make sure there's a way to do this on the livecd). Of course there's the third option of everyone purchasing a key from Verisign but.... As for non-x86 systems, Gentoo is in between a rock and a hard place. I hope there will be a similar mechanism for the user to implement their own valid key chain and remove Microsofts, but who knows. The the devs and we need to decide on a uniform way of handling this situation. - Matt --bcaec501646766baf504c27bb8e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 15, 2012 at 12:50 AM, Duncan <1i= 5t5.duncan@cox.net> wrote:
Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:

> So, anyone been thinking about this? =A0I have, and it's not prett= y.
>
> Should I worry about this and how it affects Gentoo, or not worry abou= t
> 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 t= hat
> 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. =A0Other 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 ca= se.

ARM and etc could be more problematic since MS is mandating no-unlock
there, last I read. =A0I have no clue how they can get away with that anti-=
trust-wise, but anyway... =A0But I honestly don't know enough about oth= er
than x86/amd64 platforms to worry about it, personally.

For the short term, we don't have many options beside either adding = to the documentation that the User needs to disable UEFI or wipe the curren= t valid keys and adding their own (Devs may need to make sure there's a= way to do this on the livecd). Of course there's the third option of e= veryone purchasing a key from Verisign but....

As for non-x86 systems, Gentoo is in between a rock and= a hard place. I hope there will be a similar mechanism for the user to imp= lement their own valid key chain and remove Microsofts, but who knows. The = the devs and we need to decide on a uniform way of handling this situation.= =A0

- Matt
--bcaec501646766baf504c27bb8e8--