GRUB 2.06 release

GRUB 2.06 release

[Daniel Kiper]

Hi all,

As I told during my FOSDEM 2020 presentation we are preparing for
GRUB 2.06 release. Tentative schedule is below:
  - code freeze: 15th of March, 23:59:59 UTC; everything posted after
    that date will not be considered as a release material,
  - release: taking into account last experience I think that it will
    happen no later than June; hopefully earlier; exact date depends
    on number of bugs found, etc.

So, please plan accordingly...

If you have any questions, suggestions, etc. drop me a line.

Daniel

Re: GRUB 2.06 release

[John Paul Adrian Glaubitz]

Hi!

On 2/19/20 4:01 PM, Daniel Kiper wrote:
> As I told during my FOSDEM 2020 presentation we are preparing for
> GRUB 2.06 release. Tentative schedule is below:
>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
>     that date will not be considered as a release material,
>   - release: taking into account last experience I think that it will
>     happen no later than June; hopefully earlier; exact date depends
>     on number of bugs found, etc.
> 
> So, please plan accordingly...

Let me know when you want me to start the build tests on all architectures.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06 release

[John Paul Adrian Glaubitz]

Hi!

On 2/20/20 9:46 AM, John Paul Adrian Glaubitz wrote:
> On 2/19/20 4:01 PM, Daniel Kiper wrote:
>> As I told during my FOSDEM 2020 presentation we are preparing for
>> GRUB 2.06 release. Tentative schedule is below:
>>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
>>     that date will not be considered as a release material,
>>   - release: taking into account last experience I think that it will
>>     happen no later than June; hopefully earlier; exact date depends
>>     on number of bugs found, etc.
>>
>> So, please plan accordingly...
> 
> Let me know when you want me to start the build tests on all architectures.

FWIW, it would be great if both these fixes could be included in the 2.06 release:

	* build: Disable PIE in TARGET_CCASFLAGS if needed
        * build: Move TARGET_* assignments earlier

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06 release

[Daniel Kiper]

On Tue, Feb 25, 2020 at 02:15:16PM +0100, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 2/20/20 9:46 AM, John Paul Adrian Glaubitz wrote:
> > On 2/19/20 4:01 PM, Daniel Kiper wrote:
> >> As I told during my FOSDEM 2020 presentation we are preparing for
> >> GRUB 2.06 release. Tentative schedule is below:
> >>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> >>     that date will not be considered as a release material,
> >>   - release: taking into account last experience I think that it will
> >>     happen no later than June; hopefully earlier; exact date depends
> >>     on number of bugs found, etc.
> >>
> >> So, please plan accordingly...
> >
> > Let me know when you want me to start the build tests on all architectures.
>
> FWIW, it would be great if both these fixes could be included in the 2.06 release:
>
> 	* build: Disable PIE in TARGET_CCASFLAGS if needed
>         * build: Move TARGET_* assignments earlier

All are in right now...

Matt, Mike, I added SOB on behalf of you. I hope this is not a problem for you.

Thanks,

Daniel

Re: GRUB 2.06 release

[Matt Turner]

On Fri, Feb 28, 2020 at 4:46 AM Daniel Kiper <dkiper@net-space.pl> wrote:
>
> On Tue, Feb 25, 2020 at 02:15:16PM +0100, John Paul Adrian Glaubitz wrote:
> > Hi!
> >
> > On 2/20/20 9:46 AM, John Paul Adrian Glaubitz wrote:
> > > On 2/19/20 4:01 PM, Daniel Kiper wrote:
> > >> As I told during my FOSDEM 2020 presentation we are preparing for
> > >> GRUB 2.06 release. Tentative schedule is below:
> > >>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > >>     that date will not be considered as a release material,
> > >>   - release: taking into account last experience I think that it will
> > >>     happen no later than June; hopefully earlier; exact date depends
> > >>     on number of bugs found, etc.
> > >>
> > >> So, please plan accordingly...
> > >
> > > Let me know when you want me to start the build tests on all architectures.
> >
> > FWIW, it would be great if both these fixes could be included in the 2.06 release:
> >
> >       * build: Disable PIE in TARGET_CCASFLAGS if needed
> >         * build: Move TARGET_* assignments earlier
>
> All are in right now...
>
> Matt, Mike, I added SOB on behalf of you. I hope this is not a problem for you.

Thank you, Daniel. That's perfectly okay with me.

Re: GRUB 2.06 release

[Mike Gilbert]

On Fri, Feb 28, 2020 at 6:46 AM Daniel Kiper <dkiper@net-space.pl> wrote:
>
> On Tue, Feb 25, 2020 at 02:15:16PM +0100, John Paul Adrian Glaubitz wrote:
> > Hi!
> >
> > On 2/20/20 9:46 AM, John Paul Adrian Glaubitz wrote:
> > > On 2/19/20 4:01 PM, Daniel Kiper wrote:
> > >> As I told during my FOSDEM 2020 presentation we are preparing for
> > >> GRUB 2.06 release. Tentative schedule is below:
> > >>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > >>     that date will not be considered as a release material,
> > >>   - release: taking into account last experience I think that it will
> > >>     happen no later than June; hopefully earlier; exact date depends
> > >>     on number of bugs found, etc.
> > >>
> > >> So, please plan accordingly...
> > >
> > > Let me know when you want me to start the build tests on all architectures.
> >
> > FWIW, it would be great if both these fixes could be included in the 2.06 release:
> >
> >       * build: Disable PIE in TARGET_CCASFLAGS if needed
> >         * build: Move TARGET_* assignments earlier
>
> All are in right now...
>
> Matt, Mike, I added SOB on behalf of you. I hope this is not a problem for you.

Yes, that's fine. Thanks.

Re: GRUB 2.06 release

[Daniel Kiper]

On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> Hi all,
>
> As I told during my FOSDEM 2020 presentation we are preparing for
> GRUB 2.06 release. Tentative schedule is below:
>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
>     that date will not be considered as a release material,

Just a kind reminder... Less than two weeks left...

Daniel

Re: GRUB 2.06 release

[John Paul Adrian Glaubitz]

On 3/3/20 6:26 PM, Daniel Kiper wrote:
> On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
>> Hi all,
>>
>> As I told during my FOSDEM 2020 presentation we are preparing for
>> GRUB 2.06 release. Tentative schedule is below:
>>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
>>     that date will not be considered as a release material,
> 
> Just a kind reminder... Less than two weeks left...

I really appreciate the faster release cycle. Much appreciated!

Thanks a lot for your efforts, Daniel!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06 release

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > Hi all,
> >
> > As I told during my FOSDEM 2020 presentation we are preparing for
> > GRUB 2.06 release. Tentative schedule is below:
> >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> >     that date will not be considered as a release material,
> 
> Just a kind reminder... Less than two weeks left...
> 
> Daniel

Any chance to get the Arogn2 changes in? As far as I remember we were
pending some legal issues where you've reached out to GNU, right? Please
correct me if I'm wrong here and you're waiting for me on anything
there.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: GRUB 2.06 release

[Daniel Kiper]

On Tue, Mar 03, 2020 at 06:33:54PM +0100, John Paul Adrian Glaubitz wrote:
> On 3/3/20 6:26 PM, Daniel Kiper wrote:
> > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> >> Hi all,
> >>
> >> As I told during my FOSDEM 2020 presentation we are preparing for
> >> GRUB 2.06 release. Tentative schedule is below:
> >>   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> >>     that date will not be considered as a release material,
> >
> > Just a kind reminder... Less than two weeks left...
>
> I really appreciate the faster release cycle. Much appreciated!
>
> Thanks a lot for your efforts, Daniel!

You are welcome!

Daniel

Re: GRUB 2.06 release

[Daniel Kiper]

On Wed, Mar 04, 2020 at 05:39:10AM +0100, Patrick Steinhardt wrote:
> On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > > Hi all,
> > >
> > > As I told during my FOSDEM 2020 presentation we are preparing for
> > > GRUB 2.06 release. Tentative schedule is below:
> > >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > >     that date will not be considered as a release material,
> >
> > Just a kind reminder... Less than two weeks left...
> >
> > Daniel
>
> Any chance to get the Arogn2 changes in? As far as I remember we were

Let's try... We will see how it goes. If you run over the freeze date
then I can give you an exception. However, not so long...

> pending some legal issues where you've reached out to GNU, right? Please

Yeah, I sent your question to FSF folks a few days ago. Sadly, still no reply...

> correct me if I'm wrong here and you're waiting for me on anything
> there.

What about this UEFI allocator thing? Anyway, I would suggest posting
next version for review now. Then we should have code quite quickly
hammered out. Legal stuff should not take long if we get a reply which
we more or less expect what it will be.

Daniel

Re: GRUB 2.06 release

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Thu, Mar 05, 2020 at 02:50:39PM +0100, Daniel Kiper wrote:
> On Wed, Mar 04, 2020 at 05:39:10AM +0100, Patrick Steinhardt wrote:
> > Any chance to get the Arogn2 changes in? As far as I remember we were
> 
> Let's try... We will see how it goes. If you run over the freeze date
> then I can give you an exception. However, not so long...
> 
> > pending some legal issues where you've reached out to GNU, right? Please
> 
> Yeah, I sent your question to FSF folks a few days ago. Sadly, still no reply...
> 
> > correct me if I'm wrong here and you're waiting for me on anything
> > there.
> 
> What about this UEFI allocator thing? Anyway, I would suggest posting
> next version for review now. Then we should have code quite quickly
> hammered out. Legal stuff should not take long if we get a reply which
> we more or less expect what it will be.

I forgot about that, thanks for reminding me. I'll have a look tomorrow
at whether I'm able to get it working as I interpret Leif's vision. By
the way, do you happen to know if other platforms will be impacted by
the increased memory requirement, too?

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: GRUB 2.06 release

[Daniel Kiper]

On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > Hi all,
> >
> > As I told during my FOSDEM 2020 presentation we are preparing for
> > GRUB 2.06 release. Tentative schedule is below:
> >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> >     that date will not be considered as a release material,
>
> Just a kind reminder... Less than two weeks left...

Less than a week left... This is final call...

I will review all patches which have not get my RB by the end of this week.

Daniel

Re: GRUB 2.06 release

[Daniel Kiper]

On Wed, Mar 11, 2020 at 11:47:35AM +0100, Daniel Kiper wrote:
> On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > > Hi all,
> > >
> > > As I told during my FOSDEM 2020 presentation we are preparing for
> > > GRUB 2.06 release. Tentative schedule is below:
> > >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > >     that date will not be considered as a release material,
> >
> > Just a kind reminder... Less than two weeks left...
>
> Less than a week left... This is final call...

Freeze in force! No new features are accepted at this point!

I will be reviewing all patches posted before the end of Sunday. All of
them will be considered for inclusion in the release. Additionally, all
features under active development and discussed on grub-devel still can
be considered for inclusion. However, if there is a substantial danger
of destabilizing the code or delaying the release I may reject any patch
at any point.

I am especially interested in fixes and cleanups at this point...

I am going to cut an RC in 2-4 weeks.

Daniel

Re: GRUB 2.06 release

[Daniel Kiper]

On Mon, Mar 16, 2020 at 05:41:29PM +0100, Daniel Kiper wrote:
> On Wed, Mar 11, 2020 at 11:47:35AM +0100, Daniel Kiper wrote:
> > On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> > > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > > > Hi all,
> > > >
> > > > As I told during my FOSDEM 2020 presentation we are preparing for
> > > > GRUB 2.06 release. Tentative schedule is below:
> > > >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > > >     that date will not be considered as a release material,
> > >
> > > Just a kind reminder... Less than two weeks left...
> >
> > Less than a week left... This is final call...
>
> Freeze in force! No new features are accepted at this point!
>
> I will be reviewing all patches posted before the end of Sunday. All of
> them will be considered for inclusion in the release. Additionally, all
> features under active development and discussed on grub-devel still can
> be considered for inclusion. However, if there is a substantial danger
> of destabilizing the code or delaying the release I may reject any patch
> at any point.
>
> I am especially interested in fixes and cleanups at this point...
>
> I am going to cut an RC in 2-4 weeks.

Bad news is that we have delays... :-( Good news is that everything is going
forward... :-) I merged next portion of patches yesterday. I am working
on some fixes for issues which I found. I am also trying to work out
the best solution for other bugs which are lingering here and there. So,
please be patient... However, if you have any questions or suggestions
just drop me a line...

Daniel

Re: GRUB 2.06 release

[Daniel Kiper]

On Wed, Apr 22, 2020 at 12:24:40PM +0200, Daniel Kiper wrote:
> On Mon, Mar 16, 2020 at 05:41:29PM +0100, Daniel Kiper wrote:
> > On Wed, Mar 11, 2020 at 11:47:35AM +0100, Daniel Kiper wrote:
> > > On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> > > > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > > > > Hi all,
> > > > >
> > > > > As I told during my FOSDEM 2020 presentation we are preparing for
> > > > > GRUB 2.06 release. Tentative schedule is below:
> > > > >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > > > >     that date will not be considered as a release material,
> > > >
> > > > Just a kind reminder... Less than two weeks left...
> > >
> > > Less than a week left... This is final call...
> >
> > Freeze in force! No new features are accepted at this point!
> >
> > I will be reviewing all patches posted before the end of Sunday. All of
> > them will be considered for inclusion in the release. Additionally, all
> > features under active development and discussed on grub-devel still can
> > be considered for inclusion. However, if there is a substantial danger
> > of destabilizing the code or delaying the release I may reject any patch
> > at any point.
> >
> > I am especially interested in fixes and cleanups at this point...
> >
> > I am going to cut an RC in 2-4 weeks.
>
> Bad news is that we have delays... :-( Good news is that everything is going
> forward... :-) I merged next portion of patches yesterday. I am working
> on some fixes for issues which I found. I am also trying to work out
> the best solution for other bugs which are lingering here and there. So,
> please be patient... However, if you have any questions or suggestions
> just drop me a line...

Unfortunately there are still delays due to some unexpected things
happening... Though I am still ploughing through backlog. I have
recently posted a few fixes and cleanups required for rc1. Sadly there
are still a few issues which have to be fixed. I am working on them. So,
I hope that in the following weeks we will be able to cut rc1...

If you are waiting for my review please bear with me. I will get back to
you as soon as I can. Though I am mostly looking at important fixes in
first order right now.

Daniel

Re: GRUB 2.06 release

[Daniel Kiper]

On Fri, May 29, 2020 at 02:07:29PM +0200, Daniel Kiper wrote:
> On Wed, Apr 22, 2020 at 12:24:40PM +0200, Daniel Kiper wrote:
> > On Mon, Mar 16, 2020 at 05:41:29PM +0100, Daniel Kiper wrote:
> > > On Wed, Mar 11, 2020 at 11:47:35AM +0100, Daniel Kiper wrote:
> > > > On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> > > > > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > As I told during my FOSDEM 2020 presentation we are preparing for
> > > > > > GRUB 2.06 release. Tentative schedule is below:
> > > > > >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > > > > >     that date will not be considered as a release material,
> > > > >
> > > > > Just a kind reminder... Less than two weeks left...
> > > >
> > > > Less than a week left... This is final call...
> > >
> > > Freeze in force! No new features are accepted at this point!
> > >
> > > I will be reviewing all patches posted before the end of Sunday. All of
> > > them will be considered for inclusion in the release. Additionally, all
> > > features under active development and discussed on grub-devel still can
> > > be considered for inclusion. However, if there is a substantial danger
> > > of destabilizing the code or delaying the release I may reject any patch
> > > at any point.
> > >
> > > I am especially interested in fixes and cleanups at this point...
> > >
> > > I am going to cut an RC in 2-4 weeks.
> >
> > Bad news is that we have delays... :-( Good news is that everything is going
> > forward... :-) I merged next portion of patches yesterday. I am working
> > on some fixes for issues which I found. I am also trying to work out
> > the best solution for other bugs which are lingering here and there. So,
> > please be patient... However, if you have any questions or suggestions
> > just drop me a line...
>
> Unfortunately there are still delays due to some unexpected things
> happening... Though I am still ploughing through backlog. I have
> recently posted a few fixes and cleanups required for rc1. Sadly there
> are still a few issues which have to be fixed. I am working on them. So,
> I hope that in the following weeks we will be able to cut rc1...
>
> If you are waiting for my review please bear with me. I will get back to
> you as soon as I can. Though I am mostly looking at important fixes in
> first order right now.

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

Re: GRUB 2.06 release

[Pete Batard]

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/

Re: GRUB 2.06 release

[Julian Andres Klode]

On Mon, Oct 19, 2020 at 05:30:41PM +0100, Pete Batard wrote:
> 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.

That's a misunderstanding, nobody would upgrade existing OS to 2.06, you
can't just upgrade the entire bootloader in a stable OS. You'd only
upgrade the latest in-development version and cherry-pick fixes to old
releases.

> 
> 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".

I don't understand. Just compile a new one with the cherry-picks? Sounds
weird though, you need to keep core.img around for every possible ISO
you want to build against?


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Re: GRUB 2.06 release

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]

On 10/20/20 3:00 PM, Julian Andres Klode wrote:
> On Mon, Oct 19, 2020 at 05:30:41PM +0100, Pete Batard wrote:
>> 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.
> 
> That's a misunderstanding, nobody would upgrade existing OS to 2.06, you
> can't just upgrade the entire bootloader in a stable OS. You'd only
> upgrade the latest in-development version and cherry-pick fixes to old
> releases.

Well, only rolling release distros would.

I'd like to instead propose a third option though. grub could benefit
from a policy to fork off maintenance branches for CVE fixes, and all
distros would upgrade to 2.04.1 (or 2.02.1), then later on a couple of
rolling release distros would upgrade to 2.06 once it is released.


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1601 bytes --]

Re: GRUB 2.06 release

[Pete Batard]

Hi Julian,

On 2020.10.20 20:00, Julian Andres Klode wrote:
> That's a misunderstanding, nobody would upgrade existing OS to 2.06, you
> can't just upgrade the entire bootloader in a stable OS.

We're talking about distro maintainers adding a GRUB bootloader for 
ISO/image boot. We're not talking about the case of GRUB usage with an 
installed OS.

In this case there's no upgrade to speak of. Which means that distro 
maintainers may tend to prefer a stable official dot release as their 
starting point.

> You'd only
> upgrade the latest in-development version and cherry-pick fixes to old
> releases.

Well, I'm not sure what you are trying to dispute here, but the fact is, 
ditros (right now I know of Unbuntu 20.10 and Rescuezilla, and I haven't 
really tried to look for them) are cherry picking the BootHole fixes and 
applying them to older dot releases, because there is no official dot 
release that integrates these fixes. And that *is* creating issues, no 
matter how you look at it.

>> 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".
> 
> I don't understand. Just compile a new one with the cherry-picks?

But that's the issue: Now I have to *guess* the cherry picks that these 
maintainers might have chosen, because, in the absence of an official 
release, it's a free for all with regards to what patches maintainers 
decide they want to apply on top of their base (which can generally be 
assumed to be a dot release). So it becomes a complete lottery. I can't 
go around hunting every distro to see what patches they cherry picked by 
their maintainers. And that's where having an official dot release 
helps, because distro maintainers will naturally migrate to the full 
patchset and there's no guessing involved.

? Sounds
> weird though, you need to keep core.img around for every possible ISO
> you want to build against?

Pretty much [1]. For the ISO -> USB conversion process, in non DD mode 
(and for BIOS mode), I need to provide a core.img, since that's not 
something that can be derived from the bootloader that's being used for 
optical boot, since, for one thing, it'd tend not to include the modules 
for MBR/GPT partition or FAT/NTFS file systems, which we need. So, to 
keep the application small as well as address the occasional distro 
maintainers having applied a custom patch on top of a dot release to do 
something specific for their distro, I have to go through a "detect GRUB 
version and locate a matching core.img on our server" in the Rufus 
application, so that BIOS mode can work.

And before someone states "Well, most of these ISOs should be ISOHybrid, 
so why don't you just write them in DD mode and avoid this whole mess?", 
you may want to spend some time looking on social media sites to find 
out how a non insignificant amount of Windows users are utterly 
bewildered with seeing either their USB drive "disappear" (on account of 
being converted to a file system that Windows cannot natively mount) or 
reduced to a couple MB (on account of only the ESP being reported by 
Windows) after writing it in DD mode, and ending up not running 
GNU/Linux as a result, because they believe that their media was not 
created properly. This is why Rufus, while giving the choice of writing 
in ISO or DD mode for ISOHybrid, recommends ISO mode as a default of 
people who don't know which one they should pick, as, notwithstanding of 
the BootHole issue, it usually just takes a small core.img download to 
get it working. But that means we needs a whole slew of core.img's to 
work with the various versions of GRUB that various ISOs may use, and 
the new BootHole vulnerability is throwing this whole matter into 
further disarray, as, with the lack of an official dot release that 
includes the BootHole fixes, maintainers have taken upon themselves to 
cherry pick some of these fixes and update "older" GRUB versions in a 
manner that makes then incompatible with the core.img we provide.

All in all, an official dot release with the BootHole fixes, *soon*, 
would avoid this whole mess as maintainers, a lot of which don't appear 
to be keen on working with an in-development source that they consider 
as "potentially unstable", would naturally upgrade to a dot release with 
the BootHole fixes if there was one. Hence my request to see if this can 
be sped up somewhat.

Regards,

/Pete

[1] https://github.com/pbatard/rufus-web/tree/gh-pages/files

Re: GRUB 2.06 release

[Julian Andres Klode]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

On Tue, Oct 20, 2020 at 03:12:49PM -0400, Eli Schwartz wrote:
> On 10/20/20 3:00 PM, Julian Andres Klode wrote:
> > On Mon, Oct 19, 2020 at 05:30:41PM +0100, Pete Batard wrote:
> >> 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.
> > 
> > That's a misunderstanding, nobody would upgrade existing OS to 2.06, you
> > can't just upgrade the entire bootloader in a stable OS. You'd only
> > upgrade the latest in-development version and cherry-pick fixes to old
> > releases.
> 
> Well, only rolling release distros would.
Sure
> 
> I'd like to instead propose a third option though. grub could benefit
> from a policy to fork off maintenance branches for CVE fixes, and all
> distros would upgrade to 2.04.1 (or 2.02.1), then later on a couple of
> rolling release distros would upgrade to 2.06 once it is released.

I don't know. It would have made the effort significantly harder to
rebase to 2.04.1 instead of just appending the patches to the ton
of patches we already have.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: GRUB 2.06 release

[Pete Batard]

Hi Eli,

On 2020.10.20 20:12, Eli Schwartz wrote:
> I'd like to instead propose a third option though. grub could benefit
> from a policy to fork off maintenance branches for CVE fixes, and all
> distros would upgrade to 2.04.1 (or 2.02.1), then later on a couple of
> rolling release distros would upgrade to 2.06 once it is released.

That sounds like a good alternative too.

Major vulnerabilities such as BootHole need to see some kind of 
"emergency" release(s) that focuses solely on addressing them. Whether 
it's a 2.04.1 or a fast tracking of 2.06 (and then moving the non 
vulnerability related work into a new 2.07) is up to the maintainers, as 
it's really the delay of seeing any kind of official release with the 
vulnerability fixed that is a problem.

Of course, this is easier said than done, but, to be honest, I don't 
think the apparent decision (at least that's how it looks from an 
outside perspective) of trying to fold BootHole fixes into the 2.06 
release has been for the best...

Regards,

/Pete

Re: GRUB 2.06 release

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 856 bytes --]

On 10/20/20 4:05 PM, Julian Andres Klode wrote:
> I don't know. It would have made the effort significantly harder to
> rebase to 2.04.1 instead of just appending the patches to the ton
> of patches we already have.

Why is this a grub development concern? It might be work for Debian, but
other distros might not have nearly as many patches...

If these patches are so important, *and* they are backported from
official grub commits, then they could be nominated for inclusion into
some prospective 2.04.1 maintenance release too.

Either way, having fewer patches to track on top of more up to date
official sources should always be considered a good thing. Having a
delta between upstream sources and built sources is never *good*, even
if it is often a *necessary evil*.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1601 bytes --]

Re: GRUB 2.06 release

[Daniel Kiper]

On Wed, Jul 29, 2020 at 07:46:43PM +0200, Daniel Kiper wrote:
> On Fri, May 29, 2020 at 02:07:29PM +0200, Daniel Kiper wrote:
> > On Wed, Apr 22, 2020 at 12:24:40PM +0200, Daniel Kiper wrote:
> > > On Mon, Mar 16, 2020 at 05:41:29PM +0100, Daniel Kiper wrote:
> > > > On Wed, Mar 11, 2020 at 11:47:35AM +0100, Daniel Kiper wrote:
> > > > > On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> > > > > > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > As I told during my FOSDEM 2020 presentation we are preparing for
> > > > > > > GRUB 2.06 release. Tentative schedule is below:
> > > > > > >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > > > > > >     that date will not be considered as a release material,
> > > > > >
> > > > > > Just a kind reminder... Less than two weeks left...
> > > > >
> > > > > Less than a week left... This is final call...
> > > >
> > > > Freeze in force! No new features are accepted at this point!
> > > >
> > > > I will be reviewing all patches posted before the end of Sunday. All of
> > > > them will be considered for inclusion in the release. Additionally, all
> > > > features under active development and discussed on grub-devel still can
> > > > be considered for inclusion. However, if there is a substantial danger
> > > > of destabilizing the code or delaying the release I may reject any patch
> > > > at any point.
> > > >
> > > > I am especially interested in fixes and cleanups at this point...
> > > >
> > > > I am going to cut an RC in 2-4 weeks.
> > >
> > > Bad news is that we have delays... :-( Good news is that everything is going
> > > forward... :-) I merged next portion of patches yesterday. I am working
> > > on some fixes for issues which I found. I am also trying to work out
> > > the best solution for other bugs which are lingering here and there. So,
> > > please be patient... However, if you have any questions or suggestions
> > > just drop me a line...
> >
> > Unfortunately there are still delays due to some unexpected things
> > happening... Though I am still ploughing through backlog. I have
> > recently posted a few fixes and cleanups required for rc1. Sadly there
> > are still a few issues which have to be fixed. I am working on them. So,
> > I hope that in the following weeks we will be able to cut rc1...
> >
> > If you are waiting for my review please bear with me. I will get back to
> > you as soon as I can. Though I am mostly looking at important fixes in
> > first order right now.
>
> 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

Huh... This took longer than I wanted to. Anyway, I am going to cut
2.06-rc1 by the of this week. So, this is the final call to say what is
missing in current master. I am going to take only critical code fixes
after RC. Documentation, tests, etc. changes still will be welcome.

Daniel

Re: GRUB 2.06 release

[John Paul Adrian Glaubitz]

Hi Daniel!

On 12/14/20 1:39 PM, Daniel Kiper wrote:
> Huh... This took longer than I wanted to. Anyway, I am going to cut
> 2.06-rc1 by the of this week. So, this is the final call to say what is
> missing in current master. I am going to take only critical code fixes
> after RC. Documentation, tests, etc. changes still will be welcome.

Great! Kudos and thanks to everyone who has contributed to this effort!

Let me know when you want me to run some basic tests on all Debian targets.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06 release

[Daniel Kiper]

On Mon, Dec 14, 2020 at 01:39:12PM +0100, Daniel Kiper wrote:
> On Wed, Jul 29, 2020 at 07:46:43PM +0200, Daniel Kiper wrote:
> > On Fri, May 29, 2020 at 02:07:29PM +0200, Daniel Kiper wrote:
> > > On Wed, Apr 22, 2020 at 12:24:40PM +0200, Daniel Kiper wrote:
> > > > On Mon, Mar 16, 2020 at 05:41:29PM +0100, Daniel Kiper wrote:
> > > > > On Wed, Mar 11, 2020 at 11:47:35AM +0100, Daniel Kiper wrote:
> > > > > > On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> > > > > > > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > As I told during my FOSDEM 2020 presentation we are preparing for
> > > > > > > > GRUB 2.06 release. Tentative schedule is below:
> > > > > > > >   - code freeze: 15th of March, 23:59:59 UTC; everything posted after
> > > > > > > >     that date will not be considered as a release material,
> > > > > > >
> > > > > > > Just a kind reminder... Less than two weeks left...
> > > > > >
> > > > > > Less than a week left... This is final call...
> > > > >
> > > > > Freeze in force! No new features are accepted at this point!
> > > > >
> > > > > I will be reviewing all patches posted before the end of Sunday. All of
> > > > > them will be considered for inclusion in the release. Additionally, all
> > > > > features under active development and discussed on grub-devel still can
> > > > > be considered for inclusion. However, if there is a substantial danger
> > > > > of destabilizing the code or delaying the release I may reject any patch
> > > > > at any point.
> > > > >
> > > > > I am especially interested in fixes and cleanups at this point...
> > > > >
> > > > > I am going to cut an RC in 2-4 weeks.
> > > >
> > > > Bad news is that we have delays... :-( Good news is that everything is going
> > > > forward... :-) I merged next portion of patches yesterday. I am working
> > > > on some fixes for issues which I found. I am also trying to work out
> > > > the best solution for other bugs which are lingering here and there. So,
> > > > please be patient... However, if you have any questions or suggestions
> > > > just drop me a line...
> > >
> > > Unfortunately there are still delays due to some unexpected things
> > > happening... Though I am still ploughing through backlog. I have
> > > recently posted a few fixes and cleanups required for rc1. Sadly there
> > > are still a few issues which have to be fixed. I am working on them. So,
> > > I hope that in the following weeks we will be able to cut rc1...
> > >
> > > If you are waiting for my review please bear with me. I will get back to
> > > you as soon as I can. Though I am mostly looking at important fixes in
> > > first order right now.
> >
> > 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
>
> Huh... This took longer than I wanted to. Anyway, I am going to cut
> 2.06-rc1 by the of this week. So, this is the final call to say what is
> missing in current master. I am going to take only critical code fixes
> after RC. Documentation, tests, etc. changes still will be welcome.

I merged all the patches which are needed for 2.06-rc1. However,
I discovered an issue in build of messages for translation. I have
to fix it before rc1 cut. I am going to do it at the beginning of
next year. Though I think you can start testing because code changes
are not expected at this point...

Daniel