On Tue, Mar 23, 2021 at 05:33:12PM +0100, Daniel Kiper wrote: > On Mon, Mar 22, 2021 at 08:45:27PM +0000, Colin Watson wrote:
[snip] > > rounds of security megapatches we've also seen that the amount of > > divergence between upstream and various distributions in > > security-critical code is in fact a serious problem that needs to be > > addressed, and so I'm not happy about adding more to it for things that > > touch e.g. the verifiers framework - obviously a security-critical > > component. > > > > However, we probably won't have any choice. Bugs of the form "I > > couldn't upgrade without reinstalling my entire system" are quite likely > > to be considered critical by any distribution worth its salt, regardless > > How long are you going to support such systems? 1, 5 or 10 years? This > approach makes GRUB upstream as a hostage of small MBR gaps users. > Anyway, I think we have to make users aware that small MBR gaps are not > supported any longer. Otherwise we will be playing whack-a-mole game > which we will loose sooner or later. IMHO It is doing the right thing to declare MBR gap is not supported, it is also doing the right thing to not breaking updates. We are yet to seek out or arrive at right time to have short MBR gap completely out of the game. Maybe a few years later nobody would care as the legacy pc bios is diminishing, or at some point of time everyone here would agree that we really have to blow up the limit in order to move on and convey a clear message that people who is running short mbr gap won't receive grub updates any longer unless they change it - given we have give acceptable grace period for them to do the migration ... Thanks, Michael _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
