[pkg-apparmor] thunderbird: apparmor profile prevents launching thunderbird with gdk-pixbuf >= 2.44.5

[Debian Tester]

On 2/14/2026 4:23 PM, Carsten Schoenert wrote:
> Control: tags -1 severity important
> Control: usertags -1 tb-apparmor
>
> Hi,
>
> Am 14.02.26 um 22:51 schrieb Jeremy Bícha:
> > On Sat, Feb 14, 2026 at 3:42 PM Debian Tester <frchuck278 at yahoo.com> wrote:
> >> I am sure I did not enable the Thunderbird apparmor profile. Something did,
> >> so from my perspective, the only question left for me is, what did enable
> >> the Thunderbird apparmor profile on my boxes? If it was some install
> >> script of some package in the Debian archive, then there could be some
> >> pure Debian installations that do have the Thunderbird apparmor profile
> >> enabled by default. Also, I am not convinced, based on a seven year-old
> >> README file, that every pure Debian installation now, seven years later,
> >> will have the Thunderbird apparmor profile disabled by default.
>
> why it should be enabled now (by default)?
> No, there is no other package then apparmor itself that would enable it, 
> have a look at the modification time of or similar 
> /etc/apparmor.d/disable/usr.bin.thunderbird so you will know when it was 
> modified.

The file does not exist on my box. Also, since I touched
/etc/apparmor.d/usr.bin.thunderbird today when I changed its
status from "enforce" to "complain" today, it is not easy to tell
when the change happened, if it ever happened.

One of my current up-to-date Trixie (stable) installations has a similar history
that dates back to the Jessie days.

On that current Trixie (stable) installation Thunderbird's apparmor profile is enabled,
the /etc/apparmor.d/disable directory is empty, and the /etc/apparmor.d/disable
directory has not been touched since December 29, 2017, which is also when that
directory was created:

test at trixie:/etc/apparmor.d$ sudo aa-status  --pretty-json | jq .profiles.thunderbird 
"enforce"
test at trixie:/etc/apparmor.d$ ls -l disable
total 0
test at trixie:/etc/apparmor.d$ ls -ltd disable
drwxr-xr-x 2 root root 4096 Dec 29  2017 disable
test at trixie:/etc/apparmor.d$ ls -lctd disable
drwxr-xr-x 2 root root 4096 Dec 29  2017 disable
test at kolbe:/etc/apparmor.d

I don't know why my stable installation did not get its Thunderbird apparmor profile
disabled, but I think this shows that nothing has touched my /etc/apparmor.d/disable
directory since December 29, 2017, which is in the expected time range when
Buster was in development. But it is hard to know why the /etc/apparmor.d/disable
was created on December 29, 2017 and also has not been touched since then.

I don't know if this information is enough to reproduce an upgrade path that
results in a sid or testing installation today that has the Thunderbird apparmor
profile enabled, but I think this data suggests that some upgrade paths exist that
result in a situation where the Thunderbird apparmor profile never gets disabled if
the installation goes back far enough.

Cheers.