Dear Maintainer,
after recently updates thunderbird fails to start with the message:
"Thunderbird is already running, but is not responding. To open a new window,
you must first close the existing Thunderbird process, or restart your system."

In /var/log/syslog I can find:
Apr 29 12:06:40 psala-lx2 kernel: [ 5131.606429] audit: type=1400
audit(1556532400.993:264): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5131.707820] audit: type=1400
audit(1556532401.093:265): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5131.808901] audit: type=1400
audit(1556532401.197:266): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5131.909833] audit: type=1400
audit(1556532401.297:267): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5132.010927] audit: type=1400
audit(1556532401.397:268): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5132.111760] audit: type=1400
audit(1556532401.497:269): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5132.212797] audit: type=1400
audit(1556532401.601:270): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5132.313764] audit: type=1400
audit(1556532401.701:271): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5132.414863] audit: type=1400
audit(1556532401.801:272): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:41 psala-lx2 kernel: [ 5132.515785] audit: type=1400
audit(1556532401.901:273): apparmor="DENIED" operation="file_lock"
profile="thunderbird"
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046
ouid=21046
Apr 29 12:06:46 psala-lx2 kernel: [ 5136.710721] kauditd_printk_skb: 40
callbacks suppressed
Apr 29 12:06:46 psala-lx2 kernel: [ 5136.710726] audit: type=1400
audit(1556532406.097:314): apparmor="DENIED" operation="open"
profile="thunderbird" name="/etc/ld.so.conf" pid=4393 comm="thunderbird"
requested_mask="r" denied_mask="r" fsuid=21046 ouid=0

If I disable apparmor for thunderbird (aa-disable
/etc/apparmor.d/usr.bin.thunderbird) the problem seems to be solved.

I don't know which update cause this problem any way these are the packages I
have last updated:
Commandline: packagekit role='update-packages'
Install: firebird3.0-server-core:amd64 (3.0.1.32609.ds4-14, automatic), linux-
headers-4.19.0-0.bpo.4-amd64:amd64 (4.19.28-2~bpo9+1, automatic),
libtommath1:amd64 (1.0-4, automatic), linux-image-4.19.0-0.bpo.4-amd64:amd64
(4.19.28-2~bpo9+1, automatic), libfbclient2:amd64 (3.0.1.32609.ds4-14,
automatic), libreoffice-sdbc-firebird:amd64 (1:6.1.5-3~bpo9+1, automatic),
libreoffice-style-elementary:amd64 (1:6.1.5-3~bpo9+1, automatic), libreoffice-
help-common:amd64 (1:6.1.5-3~bpo9+1, automatic), linux-
headers-4.19.0-0.bpo.4-common:amd64 (4.19.28-2~bpo9+1, automatic), libreoffice-
style-colibre:amd64 (1:6.1.5-3~bpo9+1, automatic), libboost-locale1.62.0:amd64
(1.62.0+dfsg-4, automatic), libib-util:amd64 (3.0.1.32609.ds4-14, automatic),
linux-kbuild-4.19:amd64 (4.19.28-2~bpo9+1, automatic), firebird3.0-common-
doc:amd64 (3.0.1.32609.ds4-14, automatic), firebird3.0-common:amd64
(3.0.1.32609.ds4-14, automatic), fonts-liberation2:amd64 (2.00.1-3, automatic),
python-asn1crypto:amd64 (0.24.0-1~bpo9+1, automatic)
Upgrade: gir1.2-lokdocview-0.1:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1),
libreoffice-wiki-publisher:amd64 (1.2.0+LibO5.2.7-1+deb9u7,
1.2.0+LibO6.1.5-3~bpo9+1), libreoffice-math:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-script-provider-js:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-report-builder-bin:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-sdbc-postgresql:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), linux-libc-dev:amd64 (4.9.168-1, 4.19.28-2~bpo9+1),
libreofficekit-data:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-
gtk3:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-java-common:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-base:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-core:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1),
liblibreofficekitgtk:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1),
libreoffice-l10n-it:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), linux-compiler-
gcc-6-x86:amd64 (4.9.168-1, 4.19.28-2~bpo9+1), libreoffice-librelogo:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), python3-uno:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-script-provider-python:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-base-core:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), python-cryptography:amd64 (1.7.1-3+deb9u1, 2.3-1~bpo9+1),
libreoffice-ogltrans:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-
impress:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-evolution:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), linux-image-amd64:amd64 (4.9+80+deb9u7,
4.19+104~bpo9+1), ure:amd64 (5.2.7-1+deb9u7, 6.1.5-3~bpo9+1), libreoffice-sdbc-
hsqldb:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-writer:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-common:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), linux-headers-amd64:amd64 (4.9+80+deb9u7,
4.19+104~bpo9+1), libreoffice-script-provider-bsh:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-nlpsolver:amd64 (0.9+LibO5.2.7-1+deb9u7,
0.9+LibO6.1.5-3~bpo9+1), libreoffice:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), fonts-opensymbol:amd64 (2:102.7+LibO5.2.7-1+deb9u7,
2:102.10+LibO6.1.5-3~bpo9+1), libreoffice-pdfimport:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-report-builder:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), uno-libs3:amd64 (5.2.7-1+deb9u7, 6.1.5-3~bpo9+1),
libreoffice-style-tango:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1),
libreoffice-help-en-us:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-
gnome:amd64 (1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-calc:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-base-drivers:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1), libreoffice-draw:amd64 (1:5.2.7-1+deb9u7,
1:6.1.5-3~bpo9+1), libreoffice-avmedia-backend-gstreamer:amd64
(1:5.2.7-1+deb9u7, 1:6.1.5-3~bpo9+1)
Remove: libreoffice-style-galaxy:amd64 (1:5.2.7-1+deb9u7)

If you need more infos please let me know

Piviul

Hello Piviul,

downgrading severity as AppArmor isn't officially supported and
activated for the Thunderbird package.

Am 29.04.19 um 15:21 schrieb Piviul:

The path to your profile looks unusual. In the past we had other reports
that have show that AA isn't happy if the Thunderbird profile can't be
found in the typical folder.

Maybe you will find similar issues here.

I added Vincas to the recipients who is working in the AppArmor team,
maybe he has some useful ideas to encircle the problem. Seems to be a AA
issue or AA TB profile issue in the end.

Il 30/04/19 07:51, Carsten Schoenert ha scritto:
but I'm not the one that activated apparmor for thunderbird: AFAIK in
debian stretch (debian stable) the apparmor profile is enabled by default!
is unusual for local users but is a standard path for remote users where
PCs are joined to a samba domain or where authentication is preformed
remotely.

Any way I can't understand why before last updates (that doesn't seems
concern apparmor or thunderbird) have stopped working apparmor profile
in TB

Thank you very much indeed for the time you spent in making debian better!

Piviul

Hi!

There are two things:

- installing and activating AppArmor
- activating a profile to confine a given software

The latter is sometimes done by packages but only takes effect if you
did the former.

In Stretch, AppArmor is not activated by default. Did you activate it
and use it for other software?
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"

The issue is the "psala", that does not look like a standard path to me,
or is there a software which creates such a folder? And as you say below

So to me it sounds like a non-issue. You can add a local AppArmor file
for your setup, that would allow the path you're using. So you won't
have to disable the profile altogether. In summary, it does not look
like a bug in the AppArmor profile of Thunderbird at first glance.

Cheers!
Ulrike

Il 30/04/19 10:31, Ulrike Uhlig ha scritto:
I can't remember why have installed apparmor.. even if the kernel
recommend it!
is a standard path for remote users. In this case the PC is join to a
samba domain but AFAIK every time you use remote authentication
(winbind, ldap...) the user home have a path like this.
In my opinion is an issue because this kind of path are standard for
remote users.

Piviul

Am 30.04.19 um 11:05 schrieb Piviul:
...

This may be true in your environment.
I in the opposite don't know such environments if PC is joining a
domain. I never have seen an additional folder within the /home folder
in such cases.

The AppArmor thingy isn't that intelligent and flexible to detect such
cases. And we don't know every corner case which might happen out there.
And I don't want to add extra rules for such rare cases which will fit
mostly just one person.

You will need to extend the TB profile by adding your extra rules to the
file /etc/apparmor.d/local/usr.bin.thunderbird.

Note the README file in that folder to get an idea how to use the file.

Hi,

I'm not sure there is a standard for remote homes, I've seen both
/home/$user and /home/$domain/$user. That said, have you tried
augmenting the definition of @{HOME}? See /etc/apparmor.d/tunable/home
and /etc/apparmor.d/tunable/home.d/*

Regards,
Simon

Il 30/04/19 15:00, Carsten Schoenert ha scritto:
but it was, because as I have told you, before recent updates
thunderbird has been working without any problems even with the apparmor
profile enabled.
As I have told you every remote authentication (I don't think concern
only one person) save all remote users profile in a subfolder of the
home. Furthermore in my opinion, if you write a program you have to be
compatible with standard not compatible with habit that do you think
users or programmer should use.

In my opinion you should investigate how apparmor expand the @{HOME} to
understand what is recently changed.

Piviul

Il 30/04/19 15:18, Simon Deziel ha scritto:
in effect running dpkg-reconfigure apparmor as suggested on the file
/etc/apparmor.d/tunable/home.d/ubuntu seems to solve the problem.

Piviul

Am 30.04.19 um 16:00 schrieb Piviul:

I don't think so. :)
You are on stable so no new features where added to apparmor by any
update on the package. The last update was this one.

This was introduced on 2018-03-02, this is more than a year ago. It's
obviously not the fault of the apparmor package if now something isn't
working anymore.

And again, the AA profile for Thunderbird was never activated within the
stable release and that's for a reason. The people of the Debian
AppArmor packaging are knowing that there are things that don't work as
wanted in some package, one of them is the Thunderbird package. User can
switch on the profile but are then on their own.

For sure you have looked into /usr/share/doc/thunderbird/README.apparmor
to see the explanation behind that.

No, I won't do that, or better I can't do that.

My time is to limited to dig into such corner cases. I don't have a MS
AD environment beside me nor have I some LDAP based environment to do
any work here.
I'm working on a volunteer base on the Thunderbird package like the
people of the apparmor package too. I'm willing to help but this can
only happen within a frame I can work on. And your case isn't something
I can help.

Simon has given a hint how to tune the expansion of ${HOME} within the
apparmor environment.
I'm happy to adjust the README file if someone is coming up with good
suggestion.

What make you sure the AA TB profile has ever worked and was *active*?
In my eyes it can't have worked in the past as the current rules in the
profile are to strict to work around the folder structure of your $HOME.

Hi!

[...]

:)

Maybe you accidentally upgraded to Buster or you are using a kernel that
has AA enabled by default.

Cheers!
u.

Il 30/04/19 18:45, Carsten Schoenert ha scritto:
There had been some misunderstandings and I try to smooth away them...
after recent updates in my PC, TB has stopped working and I have opened
a bug report showing some logs. You say that was AA that caused TB to
stop and the cause is an unusual home path of remote users. You show me
that was possible to add my remote user's homes to the paths of user's
homes in AA. I have discovered AA and I have enabled it in others TB in
my PCs and I have appreciated very much the effort you are doing to
enforce the security in linux systems :)
Well, but who has enabled AA in PC? I'm sure that I have not worked on
/etc in these days and I am the only one can access on it. In my opinion
there is a bug in some package update that has enabled TB AA profile...
but in effect I realize that to be believable someone else would find
this unbelievable behaviour...

Thank you indeed to all of you to make linux better.

Piviul

Il 02/05/19 09:05, Ulrike Uhlig ha scritto:
I have another PC with debian Buster and the TB profile of AA was
disabled and none had enabled it. Any way in debian I don't know if AA
is enabled by default but any way when AA is enabled the AA TB profile
it isn't.

Any way if someone else find the thunderbird apparmor profile enabled
without have manually enabled it please post his report to this bug.

Piviul

Hi,

Am 02.05.19 um 09:05 schrieb Ulrike Uhlig:

the starting email of this bugreport is showing an installed kernel from
backports. So for me it's quite obvious *why* apparmor is installed and
has activated all the profiles for the various packages that come along
with AA profiles which should be also activated then.

I can remember we have such discussions again and again from time to
time and users are surprised why Thunderbird isn't working any more as
usual or expected after some random update. So far I remember it was
always an active TB AA profile. And users are even more surprised if I
tell them the TB packaging in Stretch did never had an automatically
activated AA profile, in other words, they have it activated it by
themselves.

In this report there are two things that have come together in my eyes.

1.) An activated AA profile for Thunderbird.

2.) An different path for ${HOME} because of an membership within a
    Windows domain.

The first one isn't a big problem anymore in newer days, the current AA
profile is covering for sure about 95% of the use cases.
The second point isn't covered nicely until now in the AppArmor
installations within Debian at least. But I think also that Thunderbird
isn't the only package that will suffer from this problem and we will
need a more general solution for this. And this needs to go into
Apparmor itself instead of every body tries to implement some super
logic within their AA package profile.

Currently I've no idea how to detect a membership of a Windows domain
nicely, for sure this is solvable by some PAM voodoo. I have simply no
knowledge in this area. And I have no environment to test something. It
seems we just need to trigger a dpkg-reconfigure of AA if the PC is
within a domain membership.

Hello,

Agreed.

Thunderbird is definitely not the only package affected. There already
is a way to deal with non-standard home path: local adjustment of the
'tunables' provided by Apparmor. Those will affect every profile using
the @{HOME} variable.

I don't think it's specific to domain members as all it takes is to have
a home dir located somewhere non-standard (!= /home/$user) as the
default value for @{HOME} only permits what's common.

That said, having a dpkg-reconfigure trigger when $HOME non-standard
might be an idea, but that's a concern for Apparmor itself, not
Thunderbird :)

Regards,
Simon

Il 02/05/19 16:58, Carsten Schoenert ha scritto:
Thanks Cartsen, I was beginning to think I am fool!
well, I'm not alone...
Now I'm in the 95%... I mean, after adding in the tunables homes the
remote users homes root I have re-enabled TB AA profile and all seems to
work flawless but in a more secure manner I hope! ;)
I don't know the apparmor code and I imagine that the answer is no,
but... you can't get the user's $HOME variable?
to know if a PC is a domain member you can check it, as root, the
command "net rpc testjoin"... but the user that is opening TB can be a
domain user or a local user.

Any way Cartsten thank you very much, and remember that if you need a
tester I'm here!

Piviul

According to th Filesystem Hierarchy Standard "/home is a fairly
standard concept, but it is clearly a site-specific filesystem. The
setup will differ from host to host. Therefore, no program should rely
on this location."

Note [9] also state that "...On large systems (especially when the /home
directories are shared amongst many hosts using NFS) it is useful to
subdivide user home directories. Subdivision may be accomplished by
using subdirectories such as /home/staff, /home/guests, /home/students,
etc."

So having /home/staff/biff as home directory is allowed. I guess that
there is some occurrences of an expansion looking like "/home/$USERNAME"
that shall be changed into "$HOME".
Just my 2¢€

Not sure this is the same bug, but the symptom is similar, and the solution is the same...

After upgrade to Debian 10.2 "Buster" (and possibly some additional factors, but see below) Thunderbird would not start.

It would pop up a dialog "Your Thunderbird profile cannot be loaded. It may be missing or inaccessible".
When started from the console, it would also print "Error: Access was denied while trying to open files in your profile directory."

I initally noticed this from a user account that has its $HOME on an NFS server, server running Debian 8 "Jessie"; so I tried a few things:

* Move ~/.icedove and ~/.thunderbird out of the way: same error
* Start "thunderbird -P" (profile manager): same error
* Remove ("dpkg --remove") the apparmor package: same error
* Create a new user with $HOME also on NFS: same error
* Create a new user with $HOME under /var: same error

However, it worked again after I ran the command "aa-disable  /etc/apparmor.d/usr.bin.thunderbird".

We believe that the bug you reported is fixed in the latest version of
thunderbird, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928178@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Carsten Schoenert <c.schoenert@t-online.de> (supplier of updated thunderbird package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 22 Jun 2026 21:41:06 +0200
Source: thunderbird
Architecture: source
Version: 1:152.0-1
Distribution: experimental
Urgency: medium
Maintainer: Carsten Schoenert <c.schoenert@t-online.de>
Changed-By: Carsten Schoenert <c.schoenert@t-online.de>
Closes: 880424 882218 883245 900210 909281 914403 917613 928178 949450 949649 955380 961269 1127710 1128672 1128876 1138513
Changes:
 thunderbird (1:152.0-1) experimental; urgency=medium
 .
   [ Carsten Schoenert ]
   * [5097e09] d/control: Bump B-D for libnss3-dev
   * [5350030] New upstream version 152.0
     (Closes: #1138513)
   * [92962df] Rebuild patch queue from patch-queue branch
     Removed patch (included upstream):
     fixes/Fix-conflicting-types-for-once_flag-and-call_once-with-gl.patch
     fixes/Fix-math_private.h-for-i386-FTBFS.patch
     fixes/Fix-sandbox-to-build-with-glibc-2.43.patch
   * [46de392] d/mozconfig.default: Remove option --enable-av1
 .
   [ Christoph Goehre ]
   * [5308430] rebuild patch queue from patch-queue branch (Closes: #1128876)
 .
   [ intrigeri ]
   * [77d16c3] Don't install AppArmor policy anymore
     (Closes: #1128672, #1127710, #928178, #909281, #955380, #882218, #900210,
      #914403, #917613, #949450, #880424, #883245, #961269, #949649)
Checksums-Sha1:
 1e9bca601d3dab684f2c1e34bbd107712eb17f8e 8402 thunderbird_152.0-1.dsc
 5ed145d0f72ee7e539f3f0d40cea83ed62b1499f 12403192 thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 dbef2f6a94cec7b667931b222bdd6f0aaf9a4810 931861244 thunderbird_152.0.orig.tar.xz
 6fc9531bd0e3c27e7908228227a542966eb827f8 537512 thunderbird_152.0-1.debian.tar.xz
 41476b21bed4090bcf2c148b0178ef52d0e2f2e7 40158 thunderbird_152.0-1_amd64.buildinfo
Checksums-Sha256:
 8d348b506605fc73d56722d5a55ed9dae8af623989312e5c039786edfbe4f0f2 8402 thunderbird_152.0-1.dsc
 f4afa9846377239357e485da027035fe53762cc8100ced5cf5abca87fca7a1f8 12403192 thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 64f02562f1f4a18e39c67b07255feb5828acde86327f55b1ebe45e3ac63963ea 931861244 thunderbird_152.0.orig.tar.xz
 52abff98afbeb3859791f46e5602bbbf6982f38876f7e223d0ff1ac7bb77c778 537512 thunderbird_152.0-1.debian.tar.xz
 38ab10bf14449c38f7233f8d883b1a6ffbe412606232763f9bcaa5dcda320c03 40158 thunderbird_152.0-1_amd64.buildinfo
Files:
 cddc168c5e8bdb4c051a11b4e56831b8 8402 mail optional thunderbird_152.0-1.dsc
 27c69983d0063061996fc52794377743 12403192 mail optional thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 f49e9b967f1a1fdceec316060aef4959 931861244 mail optional thunderbird_152.0.orig.tar.xz
 d435a5b441fa39456dfa21b01881fdf3 537512 mail optional thunderbird_152.0-1.debian.tar.xz
 20c10b422095bf9f1d461c01e152c30e 40158 mail optional thunderbird_152.0-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtw38bxNP7PwBHmKqgwFgFCUdHbAFAmo5mL4ACgkQgwFgFCUd
HbCPqw/+LEBi5TrBqIfSUOoosSHHufs3R4FzJrZ6vNsK4ur6EVNNhR1u0Gc4VtEG
JIaiGg7fCDf3mgAowEIKSQpVHnqMPKpqZemfIWHNT0exdKp1RXlh9OuwGdOqg0Og
5MWrhKzrDVr7p9LmB7ilQ2V0I+xHx1zh/cG58Ar2Pp9Wn8YDlpIQmO0vp6sX2ex5
GTUYHvVrssW4L/hOAsbMu9YUnGPRiHPvj94JF7XT2JFC6mndXtiqvEOH5Oo1UluK
FcM8Xz1GsANmwB4gR7/g0f06RWEjAsOMXPU98ESaY85kRTJ4VlVvGWOknGa0Sptv
frrEG893xRFXFmnrDR7dLH8Ux1cnsGy5wpNCZeLVViuT6Pv4OIm83jijKqaGHvp3
jdD8OWx7YGbYdm+INBBnff5Y/IEEni7EIuX17/S3ZNqlLYJGPbL6OWG+pMK52+xZ
0dMFXCrSMc+xMMUHBQ/aUw3up5t4B5de51tX9kWTFv3W/qIiLdA+PpH2EGiJJJIF
Jgm9q0sAlXLC2GZW55MTbk2/jhewQOcShIRrEKFJUPzpPgeXZAAN/I47uKAzoUAW
0x/Hb0+b72NKBlK8jurZfKYBDPyxLnHSUcCbVCPj8SyzxcCHBZ12jsVhIEjUwMEH
cyFP/Ep5MDC7yo9XX+Xt4na47jktwLRJ5jRpySaIV9RfhvBHPNQ=
=jjF1
-----END PGP SIGNATURE-----