On 2/14/2026 10:02 PM, Debian Tester wrote:
> 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 <[email protected]> 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@trixie:/etc/apparmor.d$ sudo aa-status --pretty-json | jq
> .profiles.thunderbird
> "enforce"
> test@trixie:/etc/apparmor.d$ ls -l disable
> total 0
> test@trixie:/etc/apparmor.d$ ls -ltd disable
> drwxr-xr-x 2 root root 4096 Dec 29 2017 disable
> test@trixie:/etc/apparmor.d$ ls -lctd disable
> drwxr-xr-x 2 root root 4096 Dec 29 2017 disable
> test@kolbe:/etc/apparmor.d
One more interesting data point on this Trixie (stable) installation.
The /etc/apparmor.d/usr.bin.thunderbird file was touched on November 23, 2023
and created on November 27, 2023:
test@trixie:/etc/apparmor.d$ ls -lt usr.bin.thunderbird
-rw-r--r-- 1 root root 14547 Nov 23 2023 usr.bin.thunderbird
test@trixie:/etc/apparmor.d$ ls -lct usr.bin.thunderbird
-rw-r--r-- 1 root root 14547 Nov 27 2023 usr.bin.thunderbird
test@trixie:/etc/apparmor.d$
This suggests it is the result of a package update dated Nov 23 2023
that was installed on my box on Nov 27 2023.
Looks like it is the result of this entry from the Thunderbird changelog:
thunderbird (1:115.5.0-1) unstable; urgency=medium
[ intrigeri ]
* [a6be3ab] AppArmor: update profile from upstream at commit
9d3fa88cdab512e45f6fd80f067337f200d356bc
[ Carsten Schoenert ]
* [ed61fd6] New upstream version 115.5.0
Fixed CVE issues in upstream version 115.5 (MFSA 2023-52):
CVE-2023-6204: Out-of-bound memory access in WebGL2 blitFramebuffer
CVE-2023-6205: Use-after-free in MessagePort::Entangled
CVE-2023-6206: Clickjacking permission prompts using the fullscreen
transition
CVE-2023-6207: Use-after-free in ReadableByteStreamQueueEntry::Buffer
CVE-2023-6208: Using Selection API would copy contents into X11 primary
selection.
CVE-2023-6209: Incorrect parsing of relative URLs starting with "///"
CVE-2023-6212: Memory safety bugs fixed in Firefox 120, Firefox ESR 115.5,
and Thunderbird 115.5
-- Carsten Schoenert <[email protected]> Wed, 22 Nov 2023 21:50:16 +0000
So it looks to me like my stable installation, if it was upgraded to testing
or sid now, would fail to launch Thunderbird in Gnome until the user intervenes
by disabling the Thunderbird apparmor profile or at least setting it to complain
mode.
>
> 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.
