grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB 2.06 release


From: Pete Batard
Subject: Re: GRUB 2.06 release
Date: Mon, 19 Oct 2020 17:30:41 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1

Hi Daniel,

On 2020.07.29 18:46, Daniel Kiper wrote:
I think this link [1] will explain my long absence... Sorry about that.

I am going to go back to GRUB work next week. I will triage all the patches
and take all (obvious) fixes. Then I will release rc1 ASAP... All new features
will be taken after 2.06 release.

Daniel

[1] https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html

Just wanted to mention that the 2.06 release (btw, is GRUB jumping straight from 2.04 [1] to 2.06 then?) delay with the BootHole fixes is starting to create some issues as folks (e.g. Rescuezilla) have started to take upon themselves to cherry pick from the BootHole patches and apply them to things like GRUB 2.02, instead of simply upgrading to a new official release, that would include these fixes.

This has the consequence of actually breaking BIOS boot for ISO -> USB conversion utilities like Rufus (disclaimer: I am the author of Rufus), since we need to provide a matching core.img during conversion, that doesn't exist on the ISO, and obvioulsy the one we provide which was compiled around the time of release does not include the BootHole fixes, and will therefore typically fail with "symbol 'grub_calloc' not found".

The end result is that, unless we go through a costly rebuild of all our core.img's, with custom patches applied, which will of course break the ability for users to validate that these binaries match the official GRUB source, we're going to see more and more breakage as downstream GRUB users are taking it upon themselves to craft their own custom version in the absence of an official release with the BootHole fixes.

I would therefore like to raise the URGENCY of having a 2.06 release sooner rather than later, that includes the BootHole fixes. As a matter of fact, I would suggest that, as soon as a set of vulnerability like BootHole has been uncovered, all other work should be put on hold until a formal release has been issued that addresses it, as it becomes more and more damaging to let too much time pass, by trying to fold it into the next planned release.

Of course, I am also well aware that workload is the main delaying constraint, but I would urge you to consider issuing an out-of-band release as soon as a vulnerability like BootHole has been discovered, even if it's just to address that specific vulnerability, as not doing so in a timely manner effectively creates compounded issues.

Thank you,

/Pete

[1] https://ftp.gnu.org/gnu/grub/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]