From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1lXVwn-0000W9-Ve for mharc-grub-devel@gnu.org; Fri, 16 Apr 2021 17:24:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48530) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXVwj-0000UR-Pg for grub-devel@gnu.org; Fri, 16 Apr 2021 17:24:15 -0400 Received: from painless-a.thn.aa.net.uk ([2001:8b0:62::26]:51774 helo=alt2.a-painless.mh.aa.net.uk) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXVwh-0004QK-T1 for grub-devel@gnu.org; Fri, 16 Apr 2021 17:24:13 -0400 Received: from f.b.1.7.2.1.e.f.f.f.a.c.5.0.a.6.4.1.b.e.2.f.f.b.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bff2:eb14:6a05:caff:fe12:71bf] helo=riva.pelham.vpn.ucam.org) by painless-a.thn.aa.net.uk with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXVwg-0002fs-OZ; Fri, 16 Apr 2021 22:24:10 +0100 Received: from ns1.pelham.vpn.ucam.org ([172.20.153.2] helo=riva.ucam.org) by riva.pelham.vpn.ucam.org with esmtp (Exim 4.92) (envelope-from ) id 1lXVwB-0006Sq-7r; Fri, 16 Apr 2021 22:23:39 +0100 Date: Fri, 16 Apr 2021 22:23:39 +0100 From: Colin Watson To: Daniel Kiper Cc: grub-devel@gnu.org, Michael Chang , Glenn Washburn , Marco A Benatto , Javier Martinez Canillas Subject: Re: [PATCH v2] i386-pc: build verifiers API as module Message-ID: <20210416212339.GV26923@riva.ucam.org> References: <20210322152000.ebheegnkkhpqa4d3@tomti.i.net-space.pl> <20210322161626.GN26923@riva.ucam.org> <20210322151906.5946fb23@crass-HP-ZBook-15-G2> <20210322204527.GO26923@riva.ucam.org> <20210323163312.xmhzcsxfqovgm27y@tomti.i.net-space.pl> <20210324044452.GB4620@mercury> <20210326170101.bjup2bcu3trlyh6v@tomti.i.net-space.pl> <20210412131553.xd7qejacnadm2nwn@tomti.i.net-space.pl> <20210413041302.GA24779@mercury> <20210414132235.pr3jl32qb3op2e57@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210414132235.pr3jl32qb3op2e57@tomti.i.net-space.pl> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: none client-ip=2001:8b0:62::26; envelope-from=cjwatson@debian.org; helo=alt2.a-painless.mh.aa.net.uk X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 21:24:15 -0000 On Wed, Apr 14, 2021 at 03:22:35PM +0200, Daniel Kiper wrote: > On Tue, Apr 13, 2021 at 12:13:02PM +0800, Michael Chang via Grub-devel wrote: > > On Mon, Apr 12, 2021 at 03:15:53PM +0200, Daniel Kiper wrote: > > > On Fri, Mar 26, 2021 at 06:01:01PM +0100, Daniel Kiper wrote: > > > > After some thinking it seems to me we can do this. I can take "i386-pc: > > > > build verifiers API as module", "kern/misc: Move grub_printf_fmt_check > > > > to gfxmenu" and similar patches into 2.06. I will revert after the > > > > release all the patches which adds ifdefery or make code ugly and do not > > > > benefit other platforms than i386-pc. This way you will have support for > > > > small MBR gaps in 2.06 and I will have clean code after 2.06 release. > > > > > > > > Does it work for you guys? > > > > > > Does anybody care? > > > > Could you please consider not reverting them ? For me it is worse than > > keeping them as distribution specific patch, as we will have a hard time > > to explain what's going on when we have to reintroduce them in rebasing > > to commits later to 2.06. > > Colin, Michael, how long are you going to support small MBR gaps? Quite honestly? My intention is to continue supporting them until there's no viable technical alternative, or until somebody figures out how to effectively (and ethically!) collect data indicating that the number of affected users is negligible. Given the complexity of fixing affected systems, and Debian's long-standing commitment to incremental upgrades, I find myself unable to justify breaking systems in this state when it's something I can avoid. Clean code is a noble enough goal, but I rank it lower than maintaining the ability for real systems in the wild to upgrade. I certainly expect that the number of affected systems will decrease organically over time, though I have little intuition for the absolute numbers involved. The only real (anec)data point I have is that any time I release packages that unintentionally break this I get several bug reports about it in quick succession, and I generally work on the assumption that only a smallish percentage of users are engaged enough to file bug reports and so each report probably represents many more affected users; but I know this is very fuzzy. I have on my to-do list an item to add something to the Debian release notes about this, since that's a way to reach less-engaged users who won't read the GRUB manual or mailing lists. That will likely help to some extent, although I can't say how much. (That said: for various reasons my available time to contribute to GRUB has been pretty low for some years anyway, particularly since it stopped being something I did on work time, and Debian would probably be served better by a more active maintainer, so I expect to be looking around for somebody to gradually replace me over the coming months and years. So maybe it won't be me whom you need to persuade anyway ...) Cheers, -- Colin Watson (he/him) [cjwatson@debian.org]