Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable

[Simon McVittie]

On Thu, 12 Nov 2020 at 04:49:29 +0100, Marc Lehmann wrote:
> On Wed, Nov 11, 2020 at 05:07:44PM +0000, Simon McVittie <smcv at debian.org> wrote:
> > Distribution-specific SONAME bumps, without coordination with upstreams,
> > cause incompatibilities for years to come (see: libcurl) and I would
> > strongly prefer to avoid them.
> 
> I agree it is an unfortunate situation that upstream does this, but
> a) it's a debian policy violation and b) it introduces unchecked out
> of bounds accesses, which are always potential security bugs. This is
> especially troublesome as the mere display of text from untrusted sources
> can trigger this.

So, the core issue there is less that PangoFcFontClass,
PangoFcFontMapClass are no longer available for subclassing, but more
that they *were* visible in the past, and therefore code outside Pango
(like yours) might already be relying on them to continue to have the
same struct layout that they had in buster. Is that correct?

Are you aware of code in Debian that subclasses them, or is this only a
concern for non-Debian code making use of the fact that subclassing is/was
allowed? (ABI breaks are ABI breaks either way, but it matters from the
release-management point of view.)

It might be possible to revert the changes to the layout of those classes
to how they were in buster, mark them as private/deprecated/something,
and if necessary move the new functionality that upstream subsequently
added into an intermediate subclass that is then used by their in-tree
subclasses. The good news is that, because the affected versions treat
those classes as private and non-subclassable, this approach shouldn't
break anything that has been compiled against the affected versions and
expects to see the ABI that is currently in bullseye.

This sort of thing seems to be a recurring problem in libraries that have
two APIs: one facing towards "normal" users of the library (in Pango's
case this means things like a typical GTK app), and one facing towards
projects that extend the library itself (like Pango engines and
renderers), with API/ABI breaks in the typical app-facing API surface
treated as more important than API/ABI breaks in the extension API.

I am not a primary maintainer of the pango1.0 package in Debian, but the
listed maintainers have too many responsibilities and not enough time
(and so do I, but here I am answering bugmail anyway). They're welcome
to take over, but will probably say the same things I'm saying.

I am unlikely to be able to keep compatibility with the old ABI in
a long-term-sustainable way without spending a significant amount of
time doing careful and patient work to persuade upstream that this is
both necessary and viable. We do not have authority over the upstream
maintainer, who is more overworked than I am, and attempting to force
him to take action is unlikely to be effective. I don't really have
the bandwidth to do this *either*, but *someone* needs to respond to
GNOME-team bug reports, so it might as well be another thing on my
growing list of responsibilities.

If I do this, I would ask you not to jump in on upstream issues/MRs
and insist that it happen sooner: antagonizing the overworked upstream
developer is not going to make this happen quicker, and might make it not
happen at all. In particular, if we propose making Debian-specific ABI
changes or setting a Debian-specific SONAME, I expect that to be perceived
as a threat, which would harm our ability to work constructively with
that upstream in future.

> > *could* make a Debian-specific fork of Pango, and link our GTK/etc.
> 
> Bumping the soname is not forking pango, but required by debian policy.

Bumping the SONAME makes us incompatible with upstream, potentially on a
long-term basis (see libcurl, libpcre3) and should not be done lightly.
In the past, Debian has been a lot more enthusiastic about bumping SONAMEs
on a distro-specific basis, but the results of doing so keep coming back
to haunt us, and I think the project (and in particular the release team)
is coming round to a consensus that it's usually a bad idea, and should
be a last resort at best.

Pragmatically, I suspect a SONAME transition might also cause us more
crashes in the short term than the affected ABIs do: while the transition
is incomplete, apps will end up loading both the "old" and "new" Pango
into the same address space, which seems likely to be bad news. Versioned
symbols wouldn't help here because the GType system is a flat global
namespace.

    smcv