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

On 8/2/20 2:47 AM, Alessandro Baggi wrote:
> 
> Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
> > It appears that it is affecting multiple distributions including
Debian
> > and Ubuntu so it looks like the grub2 team messed up. See
> > 
> >
https://www.zdnet.com/article/boothole-fixes-causing-boot-problems-across-multiple-linux-distros/
> > 
> > 
> > Mike
> > 
> > On 8/1/2020 6:11 PM, Marc Balmer via CentOS wrote:
> > > 
> > > > Am 01.08.2020 um 23:52 schrieb Leon Fauster via CentOS
> > > > <centos at centos.org>:
> > > > 
> > > > ?Am 01.08.20 um 23:41 schrieb Kay Schenk:
> > > > > Well misery loves company but still...just truly
unfathomable!
> > > > > Time for a change.
> > > > 
> > > > I can only express my incomprehension for such statements!
> > > > 
> > > > Stay and help. Instead running away or should I say out of
the
> > > > frying pan and into the fire? :-)
> > > 
> > > The thing, RHEL and CentOS not properly testing updates, cost me
at
> > > minimum 3-4 full working days, plus losses at customer sites.
> > > 
> > > This is really a huge failure of RHEL and CentOS.
> > > 
> > > A lot of trust has been destroyed.
> 
> Hi Mike,
> 
> I'm not interested that the issue is present on Debian, Ubuntu and the
> others. Currently I'm using CentOS, I'm a CentOS user and currently
I'm
> interested what is happening on CentOS because I have machines that runs
> CentOS. If the "wrong" patch was not pushed as update so fast
(maybe
> waiting more time before release with more testing to get all cases [yes
> because when you update grub and depending on the fix you can break a
> system easily]) there would have been no problem, by the way I prefer
> wait some days (consider that I can accept the release delay of
> minor/major release) then break my systems...and without messages on ML
> announces about this type of problem does not help. Sorry I can't know
> what and when a packages is updated, why it is updated, what type of
> problem (CVE) it suffers and do my reasoning for an update process. This
> is a missing for me but I still use centos and I should not need a RHEL
> account to access to get advisories and see what applies on CentOS
> (6,7,8 and Stream).
> 
> Many of us, choose CentOS due to its stability and enteprise-ready
> feature (and because is partially/enterely backed by RH). Due to actual
> problem, many server and workstation died and it's normal that some
user
> said "A lot of trust has been destroyed." because they placed a
lot of
> trust on the pro-redhat support. On the other side, all of us can fall
> in error and this is the case (like me that I updated blindy, so its
> also my fault not only the broken update).
> 
> Only one error in many years could not destroy a distro and its
> stability reputation (I think and correct me if I'm wrong) and I hope
it
> won't happen again.
Well, I am sorry to tell you, but it most likely WILL happen again at
some point.

CentOS Linux is a rebuild of RHEL source code, nothing more.  We TRY to
validate all fixes, but if something is broken in the source code, it
will likely be borken in CentOS Linux as well.  If you need software
with Service Level Agreement type stability and timing .. that is
absolutely NOT CentOS.

We have 3 people who build updates as fast as we can and this sofware is
free and unvalidated.  We don't do any security testing .. we build and
release RHEL source code.  RHEL is what you want if you want software
assurance or the fastest release cycle or an SLA grade software release.


I have released the new shim update for el7 that should fix this issue.
-------------------------------------------------------------------------

Johnny,

Is the latest update :
shim-x64           x86_64           15-7.el7_9  

Greg

> Is the latest update :
> shim-x64           x86_64           15-7.el7_9  
No. 15-8 is.

> On Aug 2, 2020, at 9:14 AM, Gregory P. Ennis <PoMec at PoMec.Net>
wrote:
> 
> On 8/2/20 2:47 AM, Alessandro Baggi wrote:
>> 
>> Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
>>> It appears that it is affecting multiple distributions including
Debian
>>> and Ubuntu so it looks like the grub2 team messed up. See
>>> 
>>>
https://www.zdnet.com/article/boothole-fixes-causing-boot-problems-across-multiple-linux-distros/
>>> 
>>> 
>>> Mike
>>> 
>>> On 8/1/2020 6:11 PM, Marc Balmer via CentOS wrote:
>>>> 
>>>>> Am 01.08.2020 um 23:52 schrieb Leon Fauster via CentOS
>>>>> <centos at centos.org>:
>>>>> 
>>>>> ?Am 01.08.20 um 23:41 schrieb Kay Schenk:
>>>>>> Well misery loves company but still...just truly
unfathomable!
>>>>>> Time for a change.
>>>>> 
>>>>> I can only express my incomprehension for such statements!
>>>>> 
>>>>> Stay and help. Instead running away or should I say out of
the
>>>>> frying pan and into the fire? :-)
>>>> 
>>>> The thing, RHEL and CentOS not properly testing updates, cost
me at
>>>> minimum 3-4 full working days, plus losses at customer sites.
>>>> 
>>>> This is really a huge failure of RHEL and CentOS.
>>>> 
>>>> A lot of trust has been destroyed.
>> 
>> Hi Mike,
>> 
>> I'm not interested that the issue is present on Debian, Ubuntu and
the
>> others. Currently I'm using CentOS, I'm a CentOS user and
currently I'm
>> interested what is happening on CentOS because I have machines that
runs
>> CentOS. If the "wrong" patch was not pushed as update so fast
(maybe
>> waiting more time before release with more testing to get all cases
[yes
>> because when you update grub and depending on the fix you can break a
>> system easily]) there would have been no problem, by the way I prefer
>> wait some days (consider that I can accept the release delay of
>> minor/major release) then break my systems...and without messages on ML
>> announces about this type of problem does not help. Sorry I can't
know
>> what and when a packages is updated, why it is updated, what type of
>> problem (CVE) it suffers and do my reasoning for an update process.
This
>> is a missing for me but I still use centos and I should not need a RHEL
>> account to access to get advisories and see what applies on CentOS
>> (6,7,8 and Stream).
>> 
>> Many of us, choose CentOS due to its stability and enteprise-ready
>> feature (and because is partially/enterely backed by RH). Due to actual
>> problem, many server and workstation died and it's normal that some
user
>> said "A lot of trust has been destroyed." because they placed
a lot of
>> trust on the pro-redhat support. On the other side, all of us can fall
>> in error and this is the case (like me that I updated blindy, so its
>> also my fault not only the broken update).
>> 
>> Only one error in many years could not destroy a distro and its
>> stability reputation (I think and correct me if I'm wrong) and I
hope it
>> won't happen again.
> 
> Well, I am sorry to tell you, but it most likely WILL happen again at
> some point.
> 
> CentOS Linux is a rebuild of RHEL source code, nothing more.  We TRY to
> validate all fixes, but if something is broken in the source code, it
> will likely be borken in CentOS Linux as well.  If you need software
> with Service Level Agreement type stability and timing .. that is
> absolutely NOT CentOS.
> 
Gregory, Johnny, and everybody on CentOS team: Thanks a lot for great job you
are doing!

And yes, we, humble users, do realize what you just said, Gregory. We know about
?no guarantee? clause, and go with RedHat's reputation which through the
great job you are doing translates into CentOS reliability level. My reading of
many comments on this issue is, basically, the RedHat just lost a notch in the
reputation level. Hopefully, it is not new lower level now, which hopefully
again will be confirmed over long trouble-free period in a future.

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
> We have 3 people who build updates as fast as we can and this sofware is
> free and unvalidated.  We don't do any security testing .. we build and
> release RHEL source code.  RHEL is what you want if you want software
> assurance or the fastest release cycle or an SLA grade software release.
> 
> 
> I have released the new shim update for el7 that should fix this issue.
> -------------------------------------------------------------------------
> 
> Johnny,
> 
> Is the latest update :
> shim-x64           x86_64           15-7.el7_9  
> 
> Greg
> 
> 
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos

> 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?
> 
Secure booting using UEFI requires that the code is signed - that is
the "secure" bit.  Microsoft are the CA for that signing. There's
nothing sinister about it, they aren't signing the RPM package just one
of the bits of code in the package. I seem to remember that Microsoft
were the most vocal advocates for secure booting to get around boot
sector viruses and in order to facilitate a more universal uptake they
committed to signing any UEFI boot code from other OSes so long as it
came from a bona fide source.

You don't have to use UEFI secure booting - most machines can fall back
to legacy booting using BIOS settings. If you do that, you won't use
any Microsoft signed code.

I haven't looked in detail at the bug this all was supposed to fix, but
I think it had the capability of by-passing the UEFI security checking,
hence why the release of the advisory was delayed until the OSes were
patched and why there was a scramble to get everything out in time.
It's a nasty bug and was difficult to fix from what I've heard.

P.

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.