Previous patch releases had some breakage, we need to check if they were fixed. See also #65670

@jtojnar: Thanks, I will have a look.

I believe the issue was with pygtk #65670 (comment). So maybe you just need to give it some extra cflags to build now.

@worldofpeace: It doesn't seem like there is a 1.44.6-2 source tarball published on the regular mirrors (there is one on github and gitlab, but I'll try to stick with the pre-existing mechanism first) yet, but I will try out and see if we can backport this as a patch.

From IRC:

https://gitlab.gnome.org/GNOME/pango/compare/1.44.6...1.44.6-2

That should work for us. Could you try adding https://gitlab.gnome.org/GNOME/pango/commit/8a408d4f25ddb0e3d6020cdde0cd8f8a19ee8db2.patch to patches?

@jtojnar: Yes, this is the patch I was trying. While this solves the immediate error, it runs into another deprecated and removed API further down the line in:

pango.c:3822:32: error: ‘PangoFontClass’ {aka ‘struct _PangoFontClass’} has no member named ‘find_shaper’
     if (PANGO_FONT_CLASS(klass)->find_shaper)
                                ^~
pango.c:3823:38: error: ‘PangoFontClass’ {aka ‘struct _PangoFontClass’} has no member named ‘find_shaper’
         ret = PANGO_FONT_CLASS(klass)->find_shaper(PANGO_FONT(self->obj), lang, ch);  

On gitlab it sounded like this was supposed to fix pygtk, but I'm not sure if they actually built it and if so, if we have some discrepancy in config.

Let me push an updated version so that it can be tested via ofBorg.

Ouch, sorry, didn't notice the first time that the updated version is still not enough. Should I revert?

Hm, pygtk doesn't build indeed, with the same problem

https://gitlab.gnome.org/GNOME/pango/commit/48c5b52c944be0083a6c35caea86d186175b1640 is where find_shaper was dropped, reason unclear

The reason is upstream is trying to prune deprecated APIs. Unfortunately, pygtk is still reaching at us from its grave. On #gnome-hackers channel, there was some talk about post-mortem rejuvenation for pygtk.

I arrived at similar conclusions. I assune nobody feels overly enthusiastic about patching pango or being stuck witj an old version for all nixpkgs. should we consider splitting out a legacy version for pygtk and the possibly other cases until maybe sth moves upstream?

@7c6f434c: I think we probably should revert if we dont want to propagate all that pygtk breakage.

I am kind of afraid pygtk-using apps are also vulnerable to that invalid-UTF8-from-untrusted source CVE… Maybe apply the reverse of the find_shaper removal commit as a patch?

The reason is upstream is trying to prune deprecated APIs. Unfortunately, pygtk is still reaching at us from its grave. On #gnome-hackers channel, there was someone volunteering to perform post-mortem rejuvenation for pygtk. Until then, reverting the removal commit sounds good.

Agreed on ideally not having pygtk being vulnerable. I can try to patch that part up in a few hours but Id be a but worried that this could lead a but deeper than just this particular commit. From cursory glances yesterday it looked they like have been ditching a few things.

I guess another option is to try applying the CVE patch to 1.43?

I can try both avenues and test against pygtk and report back.

Alright, the backport of the CVE patch seems to work well and requires less fiddling than the reverts. I will open a PR just for this particular aspect. What do you think of making an additional PR bringing back a newer pango version, moving fixed-up 1.43.0 to a versioned attribute, attaching it to pygtk only for now and seeing if we can keep most of the software on the most recent pango until the pygtk saga resolves itself?

I think a backport security fix to 1.43 in master and releases 19.09 and 19.03, with a bump with a pin for pygtk in staging sounds good.