On Fri, 2012-07-06 at 11:02 +0200, Bastian Blank wrote:
> On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote:
> > The fundamental problem we must solve is allowing the *user* to
> > securely choose which OS she wants to install.
>
> No. The user can disable secure boot.
>
> >
On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote:
> The fundamental problem we must solve is allowing the *user* to
> securely choose which OS she wants to install.
No. The user can disable secure boot.
> Whether that OS
> follows thru an
On Fri, 6 Jul 2012, Rick Thomas wrote:
> We need a "stage-1" boot loader, signed by somebody trusted (FSF?
> SFLC?) with a key that will be recognized by the SecureBoot BIOS.
> This is an un-changable binary blob, so it can't be GPL (is this a
> problem?)
There is no reason why GPL source can't b
The fundamental problem we must solve is allowing the *user* to
securely choose which OS she wants to install. Whether that OS
follows thru and verifies all its parts is between the user and the
person or group who provided the OS (could be the user, herself, of
course!)
We need a "sta
On Mon, Jan 09, 2012 at 08:01:00PM +, Philip Hands wrote:
> On Mon, 9 Jan 2012 14:04:15 +, Wookey wrote:
[...]
> > * get our bootloaders signed by something like the 'linuxfoundation key'
> > if such a thing gets widely installed,
> > * explain to users how to get the 'debian key' install
On Mon, Jan 09, 2012 at 07:04:49PM +, Tanguy Ortolo wrote:
> Iustin Pop, 2012-01-09 19:57+0100:
> > Hmm, I might misunderstand this, but wouldn't just the grub binary need
> > to be signed? And this binary then would parse the grub.cfg file and
> > allow various kernels to boot.
>
> Negative.
On Mon, 9 Jan 2012 14:04:15 +, Wookey wrote:
> +++ Steve Langasek [2012-01-06 16:08 -0800]:
> > On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
> >
> > > It is also worth noting that an amd64 PC will probably support x64 UEFI
> > > only, so given that there is probably no UEFI-
Iustin Pop, 2012-01-09 19:57+0100:
> Hmm, I might misunderstand this, but wouldn't just the grub binary need
> to be signed? And this binary then would parse the grub.cfg file and
> allow various kernels to boot.
Negative. Or rather, at least not the way GRUB currently works, since it
embeds in it
On Mon, Jan 09, 2012 at 04:29:12PM +, Tanguy Ortolo wrote:
> Wookey, 2012-01-09 15:04+0100:
> > I assume evyone here is aware of mjg's useful posts about the issue of
> > key-management in UEFI secure boot?
> >
> > We need to do one of:
> >
> > * get our bootloaders signed by something like t
Wookey, 2012-01-09 15:04+0100:
> I assume evyone here is aware of mjg's useful posts about the issue of
> key-management in UEFI secure boot?
>
> We need to do one of:
>
> * get our bootloaders signed by something like the 'linuxfoundation key'
> if such a thing gets widely installed,
> * explai
+++ Steve Langasek [2012-01-06 16:08 -0800]:
> On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
>
> > It is also worth noting that an amd64 PC will probably support x64 UEFI
> > only, so given that there is probably no UEFI-base x86 PCs, there is no
> > point in creating correspondin
Tanguy Ortolo writes:
> Paul Wise, 2012-01-09 00:44+0100:
>> Sounds like he was asking you to name these new 32-bit only x86
>> systems that are still being produced and sold.
>
> That is right. In fact, I do not doubt there are some 32 bits only
> processors sold today, but I am not sure that the
Paul Wise, 2012-01-09 00:44+0100:
> Sounds like he was asking you to name these new 32-bit only x86
> systems that are still being produced and sold.
That is right. In fact, I do not doubt there are some 32 bits only
processors sold today, but I am not sure that they are using an UEFI. It
is very
On Mon, Jan 09, 2012 at 01:25:20AM +0100, Adam Borowski wrote:
> > Buying a nice new 64bit system for the purpose of running ancient 32bit
> > programs at high speed is still a lot more common than we would hope.
> Even worse: there's a lot of people pushing 32 bit for no obvious reason.
Just be
On 09/01/2012 08:25, Adam Borowski wrote:
> On Mon, Jan 09, 2012 at 11:08:56AM +1100, Russell Coker wrote:
>> On Mon, 9 Jan 2012, Paul Wise wrote:
>>> Sounds like he was asking you to name these new 32-bit only x86
>>> systems that are still being produced and sold.
>>
>> Buying a nice new 64bit s
On Mon, Jan 9, 2012 at 8:26 AM, Russell Coker wrote:
> You can run a 32bit application in a chroot or in a DomU under a 64bit
> environment.
>
> But the option of having a full 32bit environment is also useful. Admittedly
> it's becomming less useful as RAM >4G is becomming more common which allo
On Mon, 9 Jan 2012, Paul Wise wrote:
> > Aside from that, there is still the issue of 32bit binary-only software.
>
> I would imagine that is irrelevant to this thread since you aren't
> talking about bootloaders.
You can run a 32bit application in a chroot or in a DomU under a 64bit
environmen
On Mon, Jan 09, 2012 at 11:08:56AM +1100, Russell Coker wrote:
> On Mon, 9 Jan 2012, Paul Wise wrote:
> > Sounds like he was asking you to name these new 32-bit only x86
> > systems that are still being produced and sold.
>
> Buying a nice new 64bit system for the purpose of running ancient 32bit
On Mon, Jan 9, 2012 at 8:08 AM, Russell Coker wrote:
> Aside from that, there is still the issue of 32bit binary-only software.
I would imagine that is irrelevant to this thread since you aren't
talking about bootloaders.
PS: I'm subscribed, no need to CC.
--
bye,
pabs
http://wiki.debian.org/
On Mon, 9 Jan 2012, Paul Wise wrote:
> Sounds like he was asking you to name these new 32-bit only x86
> systems that are still being produced and sold.
Aside from that, there is still the issue of 32bit binary-only software.
Recently I moved all the 32bit stuff I support to DomUs running on 64b
On Sun, Jan 8, 2012 at 10:48 AM, Steve Langasek wrote:
> I don't understand your question. Are you confused about the existence of
> new, consumer x86 systems with 32-bit-only processors?
Sounds like he was asking you to name these new 32-bit only x86
systems that are still being produced and so
On Sat, Jan 07, 2012 at 10:12:15AM +, Tanguy Ortolo wrote:
> Steve Langasek, 2012-01-07 01:08+0100:
> >> It is also worth noting that an amd64 PC will probably support x64 UEFI
> >> only, so given that there is probably no UEFI-base x86 PCs, there is no
> >> point in creating corresponding imag
Steve Langasek, 2012-01-07 01:08+0100:
>> It is also worth noting that an amd64 PC will probably support x64 UEFI
>> only, so given that there is probably no UEFI-base x86 PCs, there is no
>> point in creating corresponding images.
>
> Your terminology is a bit muddled here. If you mean "there wi
On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
> Current status
> ==
> This is what I think we have for Debian.
> Installer image
> - ---
> I do not think we have any UEFI-bootable installer images so far.
I don't know if we do or not, but this seems to b
On Fri, Jan 6, 2012 at 6:55 PM, Ben Hutchings wrote:
> On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Hello all,
> >
> > UEFI (often called EFI, which was the name of its previous version) is a
> > new firmware interf
On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello all,
>
> UEFI (often called EFI, which was the name of its previous version) is a
> new firmware interface, which is expected to replace the BIOS on new
> PCs, as at has al
Hi,
On 2012-01-06, Tanguy Ortolo wrote:
> Debian is concerned by this standard, because it has to be supported if
> we want it to be usable on UEFI-based systems. And I think we should be
> *very* concerned by it because, if I recall correctly, UEFI is a
> requirement for the Windows 8 sticker pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello all,
UEFI (often called EFI, which was the name of its previous version) is a
new firmware interface, which is expected to replace the BIOS on new
PCs, as at has already done so on Apple PCs. While modern operating
system do not rely much on f
28 matches
Mail list logo