Package: thunderbird
Version: 1:52.5.2-1
Severity: serious
X-Debbugs-Cc: Simon Deziel <[email protected]>, Guido Günther <[email protected]>
Hi,
I've upgraded thunderbird from 1:52.5.0-1 to 1:52.5.2-1 in my test sid
VM after double-checking that
/etc/apparmor.d/disable/usr.bin.thunderbird existed and the profile
was not loaded.
The upgrade removed /etc/apparmor.d/disable/usr.bin.thunderbird
(because it's not shipped as a file owned by the package anymore) and
thus loaded the profile in enforced mode. I think this is not what was
intended with commit 8c57218.
I'm setting RC severity because enabling the AppArmor profile breaks
too much functionality, which is why we've decided to disable it
by default.
postinst got this added in 1:52.5.2-1:
# Disable apparmor on new installations and when we're
upgrading from
# a version that had it enabled by default
if test -z "$2" || dpkg --compare-versions "$2" le "1:52.5.0-1~"; then
mkdir -p /etc/apparmor.d/disable
ln -s /etc/apparmor.d/usr.bin.thunderbird
/etc/apparmor.d/disable/usr.bin.thunderbird
fi
The buggy behavior I'm reporting is caused by:
$ dpkg --compare-versions "1:52.5.0-1" le "1:52.5.0-1~"
$ echo $?
1
… which might be surprising but it does make sense.
While of course:
$ dpkg --compare-versions "1:52.5.0-1" le "1:52.5.0-1"
$ echo $?
0
… which is what the comparison should instead have been in the first
place, in the 1:52.5.2-1 upload.
But now that we got this wrong once, I think it'll be very hard to
recover and provide the intended behavior in _all_ cases. I think
we'll have to disable the profile on next upgrade again in many cases,
in order to revert the buggy change applied by this upgrade on sid
systems. I believe this could be achieved by replacing the test quoted
above with:
test -z "$2" || dpkg --compare-versions "$2" le "1:52.5.2-1"
… which is hopefully equivalent to "the package version we're
upgrading from did forcibly enable the AppArmor profile in at least
some cases when it should not have".
Sadly, in some cases this will disable the profile even though the
administrator had opted-in and manually enabled it (i.e.
we reintroduce a one-time instance of #884191). I don't know how to
fix this, and IMO we should not block on it before we address the bug
I'm reporting here, but perhaps it's worth a NEWS.Debian entry?
Cheers,
--
intrigeri
