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/
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
