Re: GRUB 2.06 release

[Pete Batard <pete@akeo.ie>]

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/