I stumbled upon this because my image loading unit tests using gdk-pixbuf2 couldn't load bmp files anymore

I think this has something to do with missing 'libpixbufloader*.so' files. see the rpmfind.net links below.

Might this link be relevant here?
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/e052a112075a19fb75f1f2ff3de4c82923de13f2



https://rpmfind.net/linux/RPM/fedora/40/x86_64/g/gdk-pixbuf2-modules-2.42.10-8.fc40.x86_64.html
```
Provides

    gdk-pixbuf2-modules
    gdk-pixbuf2-modules(x86-64)
    libpixbufloader-ani.so()(64bit)
    libpixbufloader-bmp.so()(64bit)
    libpixbufloader-gif.so()(64bit)
    libpixbufloader-icns.so()(64bit)
    libpixbufloader-ico.so()(64bit)
    libpixbufloader-pnm.so()(64bit)
    libpixbufloader-qtif.so()(64bit)
    libpixbufloader-tga.so()(64bit)
    libpixbufloader-tiff.so()(64bit)
    libpixbufloader-xbm.so()(64bit)
    libpixbufloader-xpm.so()(64bit) 
```

https://rpmfind.net/linux/RPM/fedora/updates/testing/40/x86_64/Packages/g/gdk-pixbuf2-modules-2.42.11-1.fc40.x86_64.html
```
Provides

    gdk-pixbuf2-modules
    gdk-pixbuf2-modules(x86-64)
    libpixbufloader-gif.so()(64bit)
    libpixbufloader-tiff.so()(64bit) 
```

I would increase the severity here

*** Bug 2276661 has been marked as a duplicate of this bug. ***

If anyone else is seeing this on Fedora 39, https://bodhi.fedoraproject.org/updates/FEDORA-2024-3d7508e796 could use one more negative karma to get it unpushed.

I've unpushed the F39 update, and verified the F40 update is already obsoleted (though that's strange, because it doesn't appear to be obsoleted by any update in particular).

Reassigning to gkrellm because you'll need to figure out how to live without this loader in rawhide.

so there are no koji builds for gdk-pixbuf2-2.42.11-2 for fc39 and fc40 but what about rawhide aka fc41 was this one missed?

@Michael Catanzaro, there are other applications that need these (xsane is one from the other bug).....

(In reply to a3emdot from comment #5)
> so there are no koji builds for gdk-pixbuf2-2.42.11-2 for fc39 and fc40 but
> what about rawhide aka fc41 was this one missed?

I didn't revert this change in rawhide because we should match what upstream does going forward.

(In reply to Sammy from comment #6)
> @Michael Catanzaro, there are other applications that need these (xsane is
> one from the other bug).....

Please file separate bug reports for each affected application. Applications should gracefully handle missing pixbuf loaders rather than crash, and consider switching to modern image formats if possible. If not possible, find a different library to use for displaying the image.

(In reply to Michael Catanzaro from comment #7)
> (In reply to a3emdot from comment #5)
> > so there are no koji builds for gdk-pixbuf2-2.42.11-2 for fc39 and fc40 but
> > what about rawhide aka fc41 was this one missed?
> 
> I didn't revert this change in rawhide because we should match what upstream
> does going forward.

So why was then my NEEDINFO for M. Clasen cancelled? and the Assignee for this issue changed?
He could have clarified the situation for gdk-pixbuf,
because it looks like he is also in charge for doing the branch merges of the gdk-pixbuf upstream repo.

https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/network/master?ref_type=heads

For me it is a problem, when format support (clearly a gdk-pixbuf feature) is disabled within a tiny increment of version number 2.42.(X -> X+1).
If this was intentional, I would still consider this a regression even for rawhide.
And if it was intentional, then why wasn't the major or even minor version increased?

The impact might be bigger than this bug report here might suggest
```
$ uname -a
Linux localhost.localdomain 6.8.6-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 13 16:12:56 UTC 2024 x86_64 GNU/Linux
$ dnf repoquery --whatdepends gdk-pixbuf2 | wc -l
Last metadata expiration check: 0:02:45 ago on Wed 24 Apr 2024 11:29:12 PM CEST.
1730
```

Hey, these loaders are going away because they're security critical and also unmaintained. Unsandboxed image decoders are bad news; cutting down the number of lesser-used formats isn't sufficient to make gdk-pixbuf safe, but at least reduces the attack surface. I don't see any point in reintroducing these loaders in rawhide because they're just going to go away again in a future update. All software that depends on them needs to take action. Sorry....

Emmanuele has created a gdk-pixbuf-extra package upstream to save the , but this project is designed to be abandonware. I recommend not packaging it for Fedora.

We'll need it for OpenSlide (otherwise I'd have to pull the BMP loader into the OpenSlide codebase, which doesn't really help anyone else) so I do plan to pursue packaging it for Fedora if no one else gets there first.  Maybe we can move this issue back to gdk-pixbuf as a placeholder until that happens?

@mcatanza
I acknowledge the pain with these older image formats.
Do you have some good examples for already existing sandboxed image decoders in mind?

Please consider communicating this problem in a more prominent way
in order to create a discussion with developers and the end users
who usually want to 'only' open some old existing image files they have
or which need to adhere to some existing process and hence need some arguments to improve the situation.

If old image formats really have to go because of unfixable design flaws,
I would consider it bad for security, if we get hundreds of badly and unmaintained new libraries afterwards.

@mcatanza
Please consider initiating a bigger effort for cleaning up these >1500 packages
via a change request for Fedora 41 or Fedora 42

(In reply to Benjamin Gilbert from comment #10)
> We'll need it for OpenSlide (otherwise I'd have to pull the BMP loader into
> the OpenSlide codebase, which doesn't really help anyone else) so I do plan
> to pursue packaging it for Fedora if no one else gets there first.  Maybe we
> can move this issue back to gdk-pixbuf as a placeholder until that happens?

OK, I'll move it back, but I doubt it will be acted on here.

I would actually recommend copying the BMP loader into the OpenSlide codebase if you're not able to change the image format. That's surely less risk than installing gdk-pixbuf-extras systemwide. (But I'm not sure it will be that easy, because use via existing APIs will surely expect the loader to be installed on the system.)

(In reply to a3emdot from comment #11)
> @mcatanza
> I acknowledge the pain with these older image formats.
> Do you have some good examples for already existing sandboxed image decoders
> in mind?

glycin-loaders (which I fear is probably only usable by Rust apps) is the only one that I'm aware of.
 
> Please consider communicating this problem in a more prominent way
> in order to create a discussion with developers and the end users
> who usually want to 'only' open some old existing image files they have
> or which need to adhere to some existing process and hence need some
> arguments to improve the situation.

I agree that better communication is important, but that's not going to be fixed in a downstream issue tracker. :)

> If old image formats really have to go because of unfixable design flaws,
> I would consider it bad for security, if we get hundreds of badly and
> unmaintained new libraries afterwards.

To be clear:

 * gdk-pixbuf is unsafe, period (if you are loading an untrusted image)
 * Removing obscure decoders makes it somewhat safer, but doesn't make the remaining decoders safe to use

(In reply to Michael Catanzaro from comment #13)
> OK, I'll move it back, but I doubt it will be acted on here.

Yup, it's just so there's a tracking bug pending the new package.  I'll self-assign so it's off mclasen's plate.

> I would actually recommend copying the BMP loader into the OpenSlide
> codebase if you're not able to change the image format. That's surely less
> risk than installing gdk-pixbuf-extras systemwide.

I get where you're coming from, I really do.  But also, I'd rather not contribute to a world where a bunch of upstreams bundle modified copies of old gdk-pixbuf loaders.

I wish there was a solid alternative to recommend.

*** Bug 2282034 has been marked as a duplicate of this bug. ***

This bug affects also xsane by bug 2277187

*** Bug 2277751 has been marked as a duplicate of this bug. ***

On Fedora 41+, the affected loaders have now been moved to the gdk-pixbuf2-modules-extra package.  Packages that need these loaders at runtime should use:

%if 0%{?fedora} >= 41
Requires: gdk-pixbuf2-modules-extra%{?_isa}
%endif

and similarly with BuildRequires if needed for tests.  I've updated OpenSlide and submitted packaging PRs for GKrellM, GVim, perl-Gtk3, and XSane:

https://src.fedoraproject.org/rpms/gkrellm/pull-request/1
https://src.fedoraproject.org/rpms/vim/pull-request/31
https://src.fedoraproject.org/rpms/perl-Gtk3/pull-request/1
https://src.fedoraproject.org/rpms/xsane/pull-request/3

FEDORA-2024-96f88c8292 (gkrellm-2.3.11-17.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-96f88c8292

FEDORA-2024-96f88c8292 (gkrellm-2.3.11-17.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.