Hi,
If you are CCed on this mail, then action is required (mat2) or
recommended (libavif, jpegxl, gdk-pixbuf2-modules-extra,
webp-pixbuf-loader).
I propose some *mildly* disruptive changes for the gdk-pixbuf2 package
in rawhide and also F43. (I was tempted to do this only in rawhide, but
the F43 package is not in great state currently, and I think it's
probably best to just push forward here.)
First, gdk-pixbuf-thumbnailer will no longer be built. It is currently
broken in F43 and upstream recommends that we stop building it
altogether. It is obsoleted by glycin-thumbnailer, which works well.
(Although jxl support seems to be broken, which we'll need to debug.)
All of gdk-pixbuf's own loaders except the Glycin loader are now
obsolete and are no longer used, so let's stop building them. I will
have gdk-pixbuf2 Obsoletes: its gdk-pixbuf2-modules subpackage. This
subpackage is currently required by gtk2, gtk3, and gtk4, which we will
rebuild. It's also required by mat2. You can generally just remove the
dependency on gdk-pixbuf2-modules. (Or replace it with a dependency on
gdk-pixbuf2 itself, if you have a package that does not link to
libgdk_pixbuf-2.0.so and requires an explicit dependency.) Glycin
supports a wide variety of image formats and is also sandboxed to
hopefully greatly improve security, so there's considerable advantage
to preferring it over other loaders.
Most third-party loaders are now also obsolete, including
avif-pixbuf-loader from libavif, jxl-pixbuf-loader from libjxl,
rsvg-pixbuf-loader from librsvg, and the standalone webp-pixbuf-loader.
I will add Obsoletes in the gdk-pixbuf2-package. These loaders will
never get used because Glycin receives precedence. I suggest retiring
webp-pixbuf-loader. For libavif/jpegxl, my recommendation is review the
build flags to disable building the gdk-pixbuf support, and remove the
subpackages that provide the pixbuf loaders. I will do this for
rsvg-pixbuf-loader.
Other third-party loaders may or may not be obsolete. The question is
whether the image format is supported by Glycin. If so, then the loader
will never be used and you might as well get rid of it. But if not
supported by Glycin, then gdk-pixbuf will still use your loader.
https://gitlab.gnome.org/GNOME/glycin#supported-image-formats
I'm expecting that all of the above should be noncontroversial,
although Glycin's support for some image formats might not be as good
as the original loaders.
I have checked our gdk-pixbuf2-modules-extra package. I think the BMP,
ICO, PNM, and TGA loaders are now obsolete and can safely be disabled.
The other loaders provided by this package are still needed, but they
cover particularly obscure image formats, so I wonder whether we still
need gdk-pixbuf2-modules-extra at all. I suspect this package exists
mainly for the BMP, ICO, and possibly TGA loaders? So maybe the package
is no longer needed? Remember that websites can download images to your
downloads directory and trigger a thumbnailer without any user
intervention (by default, yes I know Firefox can be configured to ask
permission before starting a download), so the attack surface of all of
these unsandboxed plugins is effectively web-exposed and an attacker
will target whichever is most obscure and least secure. So it would be
a considerable security win if we could retire this package. Benjamin,
what do you think? I've just tested BMP using glycin-thumbnailer and I
see thumbnails in nautilus, so I expect it should hopefully work for
the applications that you care about.
Michael
P.S. Yes it sure would have been nice to do a change proposal for this,
but too late unless we want to downgrade gdk-pixbuf release in F43,
which I suggest we not do.
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
