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

[Marc Lehmann]

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.

If you think that this bug report is a bit muddled I can open a new bug
only about the policy vioaltion and memory corruption issue, so there is
no confusion about header files or other incompatiiblities, which are a
separate issue.

> It is also the upstream developer who decides which parts of a library are
> or aren't considered to be part of the public API/ABI.

True, but in this case, the developer has decided that the relevant parts
ARE part of the public ABI. A developer cannot undo this, just as a
developer cannot make 1=2, no matter how much she or he insist on it.

(which the pango developers don't do btw., it's not disputed that the
relevant parts are part of the public ABI, all that the pango developers
have said is that they don't have the manpower to bump the soname when on
breaking changes).

> Yes, reclassifying public API/ABI as private breaks derived projects
> that were relying on it,

Not only that, they also introduce random memory corruption and potential
security bugs.

Please note that the problem is not reclassifying the public ABI as
private, the problem is breaking the ABI without bumping the soname
introducing serious actual bugs.

Reclassifying thew ABI as private would not have caused this, neither
would breaking the ABI and bumping the soname cause this kind of issue.

> and it's unfortunate that the Pango maintainers were unaware
> that derived projects were relying on this part of the API

The pango maintainers obviously were aware of that, because it's
documented in the pango documentation multiple timesa and in the nissue I
reported they admitted they were aware of it, but don't care (apparently
because it is just too much work, a fair point).

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

Note that bumping thew soname is all that's required to fix this issue, even
if the fix is not to my liking, but keep in mind this escalated from "some
ABI/API is no longer accessible" to "

> I'm sorry that this has broken your use-case, but I don't think taking
> an adversarial tone is going to help you to achieve the result you are
> aiming for.

Can you point out where I have taken "adversial tone"? What I reported is
a policy violation and apart from that a serious issue (unchecked memory
accesses that can be triggered simply by displaying text).

> People who perceive that they are being attacked will tend to
> become increasingly defensive and unwilling to change their position,
> which is presumably the opposite of what you want.

I suppose the bets way to proceed for you is to not feel attacked - I am
not aware of attacking you, and if you wrongly got the impression I did,
rest assured that this was not the intent of my words, I respect you as a
fellow human and so on.

Since this is cleared up, I hope we can go back to the actual etchnical
issues here?

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\