Re: [PATCH v2] i386-pc: build verifiers API as module

[Daniel Kiper]

On Mon, Mar 22, 2021 at 08:45:27PM +0000, Colin Watson wrote:
> On Mon, Mar 22, 2021 at 03:19:06PM -0500, Glenn Washburn wrote:
> > On Mon, 22 Mar 2021 16:16:26 +0000
> > Colin Watson <cjwatson@debian.org> wrote:
> > > On Mon, Mar 22, 2021 at 04:20:00PM +0100, Daniel Kiper wrote:
> > > > NAK for this patch and others "fixing" small MBR gaps. I am not
> > > > going to deal with this kind of issues any longer because a few
> > > > folks in the world cannot/do not want/... reinstall their systems.
> > > > Sorry guys.
> > >
> > > I'd just like to say that I think this is an unfortunate mistake, and
> > > puts distributions in an invidious position.
> >
> > Forgive my ignorance, this seems like a fairly simple patch. While I
> > personally do not like maintaining patches just solely for myself, my
> > understanding is that distros are quite accustomed to carrying patches
> > for very long periods of time (indefinitely?). Is part of the push back
> > because its onerous for distro/package maintainers? Or is this more a
> > coming from a matter of principal?

First of all, I am not going to make anybody lives more difficult just
for the sake of making it more difficult. However, I want to make my
life as a maintainer easier.

> We certainly can and do carry our own patches, but it's pretty
> unsatisfying when the reasons for rejecting them upstream don't actually
> make sense (as for "buffer: Sync up out-of-range error message" and
> "kern/dl: Disable grub_dl_unload_unneeded").  In the last couple of

OK, I was imprecise. Sorry about that. In general I am OK with the
patches which are beneficial not only for the i386-pc (I will take
closer look at above mentioned patches shortly). Though I am against
introducing piles of ifdefery, especially into security critical stuff,
to make GRUB i386-pc work with small MBR gaps. Or move code around and
make it ugly just for the same thing.

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

> of whether upstream cares about them, and so this is likely to be just
> another way in which in practice distributions end up diverging from
> upstream.  I think that's worth at least a bit of pushback.

Again, believe me, this is not my goal...

Daniel