From: Julian Andres Klode <julian.klode@canonical.com>
To: grub-devel@gnu.org
Subject: Re: GRUB 2.06 release
Date: Tue, 20 Oct 2020 22:05:50 +0200 [thread overview]
Message-ID: <20201020200550.wv272nck4u3m4kmi@jak-t480s> (raw)
In-Reply-To: <d9b199e3-e2ae-3e32-935c-61749f869900@archlinux.org>
[-- 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 --]
next prev parent reply other threads:[~2020-10-20 20:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 15:01 GRUB 2.06 release Daniel Kiper
2020-02-20 8:46 ` John Paul Adrian Glaubitz
2020-02-25 13:15 ` John Paul Adrian Glaubitz
2020-02-28 12:46 ` Daniel Kiper
2020-02-28 18:26 ` Matt Turner
2020-02-29 1:40 ` Mike Gilbert
2020-03-03 17:26 ` Daniel Kiper
2020-03-03 17:33 ` John Paul Adrian Glaubitz
2020-03-05 13:34 ` Daniel Kiper
2020-03-04 4:39 ` Patrick Steinhardt
2020-03-05 13:50 ` Daniel Kiper
2020-03-07 16:29 ` Patrick Steinhardt
2020-03-11 10:47 ` Daniel Kiper
2020-03-16 16:41 ` Daniel Kiper
2020-04-22 10:24 ` Daniel Kiper
2020-05-29 12:07 ` Daniel Kiper
2020-07-29 17:46 ` Daniel Kiper
2020-10-19 16:30 ` Pete Batard
2020-10-20 19:00 ` Julian Andres Klode
2020-10-20 19:12 ` Eli Schwartz
2020-10-20 20:05 ` Julian Andres Klode [this message]
2020-10-20 20:33 ` Eli Schwartz
2020-10-20 20:06 ` Pete Batard
2020-10-20 20:03 ` Pete Batard
2020-12-14 12:39 ` Daniel Kiper
2020-12-14 12:44 ` John Paul Adrian Glaubitz
2020-12-23 23:25 ` Daniel Kiper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201020200550.wv272nck4u3m4kmi@jak-t480s \
--to=julian.klode@canonical.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.