CentOS - Aug 2020 - Boot failed on latest CentOS 7 update

On 02/08/2020 16:26, Valeri Galtsev wrote:
> 
> On the side note: it is Microsoft that signs one of Linux packages now. We
seem to have made one more step away from ?our? computers being _our computers_.
Am I wrong?
> 
> Valeri
> 
Microsoft are the Certificate Authority for SecureBoot and most 
SB-enabled hardware (most x86 hardware) comes with a copy of the 
Microsoft key preinstalled allowing binaries that are signed by 
Microsoft to work. In the case of linux, that is the shim which becomes 
the root of trust to load everything else. If you are not happy with 
that you can always become your own certificate authority by generating 
your own keys, install your signing keys in the hardware's firmware (MOK 
list) and sign stuff yourself to use on your own machine(s).

However if you wish to distribute stuff to others and have it work 
seamlessly on hardware outside of your direct control and without the 
need for every user to import your CA SecureBoot signing key into the 
MOK list on every device, you would rely on Microsoft to sign SB related 
content.

On Sun, Aug 2, 2020 at 11:45 AM Phil Perry <pperry at elrepo.org> wrote:
> On 02/08/2020 16:26, Valeri Galtsev wrote:
> >
> > On the side note: it is Microsoft that signs one of Linux packages
now.
> We seem to have made one more step away from ?our? computers being _our
> computers_. Am I wrong?
> >
> > Valeri
> >
>
> Microsoft are the Certificate Authority for SecureBoot and most
> SB-enabled hardware (most x86 hardware) comes with a copy of the
> Microsoft key preinstalled allowing binaries that are signed by
> Microsoft to work. In the case of linux, that is the shim which becomes
> the root of trust to load everything else. If you are not happy with
> that you can always become your own certificate authority by generating
> your own keys, install your signing keys in the hardware's firmware
(MOK
> list) and sign stuff yourself to use on your own machine(s).
>
> However if you wish to distribute stuff to others and have it work
> seamlessly on hardware outside of your direct control and without the
> need for every user to import your CA SecureBoot signing key into the
> MOK list on every device, you would rely on Microsoft to sign SB related
> content.
>
>
now, does Microsoft have to sign each released module themselves, or will
they issue a CA  cert to an authorized OS creator, like RH, then let RH
sign their own modules?

EG,    Microsoft RootCA -> Signed Package
vs,      Microsoft RootCA -> RH Child CA -> Signed Package ....





-- 
-john r pierce
  recycling used bits in santa cruz

On 02/08/2020 19:54, John Pierce wrote:
> On Sun, Aug 2, 2020 at 11:45 AM Phil Perry <pperry at elrepo.org>
wrote:
> 
>> On 02/08/2020 16:26, Valeri Galtsev wrote:
>>>
>>> On the side note: it is Microsoft that signs one of Linux packages
now.
>> We seem to have made one more step away from ?our? computers being _our
>> computers_. Am I wrong?
>>>
>>> Valeri
>>>
>>
>> Microsoft are the Certificate Authority for SecureBoot and most
>> SB-enabled hardware (most x86 hardware) comes with a copy of the
>> Microsoft key preinstalled allowing binaries that are signed by
>> Microsoft to work. In the case of linux, that is the shim which becomes
>> the root of trust to load everything else. If you are not happy with
>> that you can always become your own certificate authority by generating
>> your own keys, install your signing keys in the hardware's firmware
(MOK
>> list) and sign stuff yourself to use on your own machine(s).
>>
>> However if you wish to distribute stuff to others and have it work
>> seamlessly on hardware outside of your direct control and without the
>> need for every user to import your CA SecureBoot signing key into the
>> MOK list on every device, you would rely on Microsoft to sign SB
related
>> content.
>>
>>
> now, does Microsoft have to sign each released module themselves, or will
> they issue a CA  cert to an authorized OS creator, like RH, then let RH
> sign their own modules?
> 
> EG,    Microsoft RootCA -> Signed Package
> vs,      Microsoft RootCA -> RH Child CA -> Signed Package ....
> 
> 
I believe Microsoft signs the shim which then becomes the trusted 
authority and embeds RH (or CentOS) signing cert, so (I believe) every 
release of the shim needs to be signed by Microsoft. So it's not quite 
as efficient as MS signing a RH/CentOS CA key, but is not far off.