Bug#882047: [pkg-apparmor] Bug#882047: Bug#882047: Bug#882047: apparmor-utils: aa-complain thunderbird fails
Vincas Dargis: > Also, some temporary files like > "usr.lib.libreoffice.program.soffice.binc3d3lu5x~" > are left when aa-enforce fails: Could you please report a bug upstream (https://bugs.launchpad.net/apparmor/+filebug) or worst case a dedicated one in Debian about this? Thanks in advance!
Bug#905437: libreoffice-common: AppArmor denies access to mesa shader cache
Vincas Dargis: > Cool, I will work on MR. :))) Also, would be good to have a 2.13.x upstream release with the fixes/improvements we need. > "Why not" could be "don't want to manage backports too much" :) . Right, at least not without being aware of a real need. Cheers, -- intrigeri
Bug#900388: not fixed in parcimonie 0.11.0-1
Control: tag -1 + moreinfo
Hi Paul,
intrigeri:
>>> - Don't bloat the logs with fingerprints of keys that could not
>>>be found (Closes: #900388). Also, hide spurious
>>>"dirmngr:Network:/usr/bin/dirmngr:1:1:" output.
>> This doesn't seem to have fixed the problem for me after a reboot.
> Ouch, too bad. Reopened.
I'm sorry I have no idea what's going on:
- I cannot reproduce this locally even though I have plenty of keys in my
keyring that are not on the keyservers.
- I've copied one of your sample errors
('gpg: key "0123456789ABCDEF0123456789ABCDEF01234567" not found: Not found'),
passed it through the regexp and it successfully filters it out.
Could you please:
- apply the attached patch
- kill + start parcimonie
- send me the relevant bits of the Journal (ideally, redirecting its
output to a file and signing that file, to ensure the text is not
mangled in transit)
Thanks in advance.
Cheers,
--
intrigeri
diff --git a/lib/App/Parcimonie/Daemon.pm b/lib/App/Parcimonie/Daemon.pm
index 2a5f1b1..918b811 100644
--- a/lib/App/Parcimonie/Daemon.pm
+++ b/lib/App/Parcimonie/Daemon.pm
@@ -363,6 +363,7 @@ sub tryRecvKey {
# gpg: keyserver receive failed: No data
# gpg: key "0123456789ABCDEF0123456789ABCDEF01234567" not found: Not found
# ... followed by " at /path/to/App/Parcimonie/Daemon.pm line 350"
+warn $self->encoding->encode("before filtering: " . $filtered_gpg_error);
$filtered_gpg_error =~ s{
^gpg:\s+
(?:
@@ -378,7 +379,7 @@ sub tryRecvKey {
)?
[\n]*
}{}xmsg;
-warn $self->encoding->encode($filtered_gpg_error)
+warn $self->encoding->encode("after filtering: " . $filtered_gpg_error)
if length($filtered_gpg_error);
}
}
Bug#887382: Release clojure1.9 on the masses
Elana Hashman: > This is ready to migrate down to testing now. Great news! > I was waiting for two things: > - ensure 1.9 and 1.8 can be simultaneously installed (required fixing > the alternatives logic) > - piuparts tests actually passed > These are both fixed so let us loose 1.9 on the world of testing > users. Thanks a lot for the clarification!
Bug#981442: apparmor: Please do not install by default or depend on python3
Hi Samuel,
Thanks for bringing this to our attention. For now I'll focus on
trying to understand the scope and severity of this problem.
Samuel Thibault (2021-01-31):
> As of Debian bullseye alpha3, apparmor is getting installed by default
> even in the base system,
To be clear, in this context "base system" is d-i terminology, right?
> bringing with it python3 and thus 30MB of
> various stuff that didn't used to get installed in the past, which I do
> not think we want.
Could you please confirm whether "in the past" means "in Stretch and
older" here, or something else?
I'm asking because AFAICT, the chain of dependencies has not changed
between Buster and Bullseye:
- the Linux kernel images Recommends: apparmor
- apparmor depends python3:any
> Could you have a look at not installing apparmor by default,
For context, the current (Buster, Bullseye) status of enabling
AppArmor by default is the outcome of years of work and of a long
discussion on -devel@ ("Let's enable AppArmor by default (why not?)"
starts at 857eyij4fb@boum.org, August 2017). This of course does
not imply it's set in stone nor that we can't improve things :)
> or avoid making it hardly depend on python3?
I did not check how hard that would be yet. If this is a post-Buster
regression, I'll do my best to look into it shortly!
Cheers!
Bug#981442: [pkg-apparmor] Bug#981442: apparmor: Please do not install by default or depend on python3
intrigeri (2021-02-01): >> or avoid making it hardly depend on python3? > > I did not check how hard that would be yet. If this is a post-Buster > regression, I'll do my best to look into it shortly! The only reason why apparmor "Depends: python3" in current testing/sid is that /usr/sbin/aa-status is written in Python. Upstream commit 8f9046b1b179190d0003ae1beacf460ee93c5090, included in upstream 3.0.0 release, and thus in Debian experimental already, ported that program to C, which should allow dropping the dependency on python3. I did not check how hard it would be to backport this commit. There's some more context in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1865519
Bug#981442: apparmor: Please do not install by default or depend on python3
Hi Samuel, tl;dR: Help! I have a tentative fix ready, but in order to see this fixed in Bullseye, someone else has to test the tentative fix by Saturday, 17:00 UTC. Samuel Thibault (2021-02-01): > intrigeri, le lun. 01 févr. 2021 09:16:23 +0100, a ecrit: >> > or avoid making it hardly depend on python3? >> >> The only reason why apparmor "Depends: python3" in current testing/sid >> is that /usr/sbin/aa-status is written in Python. >> >> Upstream commit 8f9046b1b179190d0003ae1beacf460ee93c5090, included in >> upstream 3.0.0 release, and thus in Debian experimental already, >> ported that program to C, which should allow dropping the dependency >> on python3. I did not check how hard it would be to backport >> this commit. > > That would be great to backport! I did the backporting work in a topic branch: https://salsa.debian.org/apparmor-team/apparmor/-/tree/debian-bug-981442 The resulting apparmor binary package has no dependency on python3. Salsa CI will tell us about obvious breakage in other areas, but AFAICT it does not exercise aa-status, so that's not sufficient to make me comfortable uploading this significant dependency change, so close to the freeze, in a package we install by default on any system that has a Linux kernel. I would like this to be tested: 1. build packages from the debian-bug-981442 branch 2. install the resulting apparmor binary package into a testing/sid VM (I don't think a chroot will do) that has no python3 installed 3. ensure step 2 did not install python3 4. ensure aa-status works (compare with how it works in a regular testing/sid system) If you, or someone else, has time to go through this test procedure by Saturday 17:00 UTC, and if the test result is successful, then I'll try hard to upload on Saturday night (UTC), which should hopefully allow this improvement to migrate to testing in time for the freeze :) Thanks for caring about the size of minimal systems installed by d-i! Cheers!
Bug#981205: [pkg-apparmor] Bug#981205: apparmor: annotate Build-Depends with
Control: tag -1 + pending Hi Helmut, Helmut Grohne (2021-01-27): > As such, both can be annotated and thus become irrelevant > to cross building and bootstrapping. Please consider applying the > attached patch. Good catch and thanks for the patch! I'll upload ASAP. Have a nice day, i.
Bug#981442: apparmor: Please do not install by default or depend on python3
Control: tag -1 + pending Hi, Samuel Thibault (2021-02-05): > I tried a bit with the base system, got […] Thanks a lot! > I'll keep the VMs around, for any further test you'd want? No, that's good enough for me. I'll upload ASAP. Cheers!
Bug#980974: apparmor blocks cups backend outgoing network connections
Hi, Brian Potkin (2021-01-25): >> Jan 23 23:39:29 debian kernel: audit: type=1400 audit(1611445169.589:22): >> apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2172 >> comm="cupsd" capability=12> If cupsd legitimately needs to use the CAP_NET_ADMIN Linux [capability], then adding this line to /etc/apparmor.d/usr.sbin.cupsd should fix it: capability net_admin, >> Jan 23 23:39:29 debian audit[2174]: AVC apparmor="DENIED" >> operation="capable" profile="/usr/sbin/cups-browsed" pid=2174 >> comm="cups-browsed" capability=23 capname="sys_nice" If cups-browsed legitimately needs to use the CAP_SYS_NICE Linux [capability], then adding this line to /etc/apparmor.d/usr.sbin.cups-browsed should fix it: capability sys_nice, In both cases, I don't know enough about how the CUPS software works to evaluate whether accepting this by default is desirable. In particular, I have never heard of "TCP connections from cupsd to backend driver" before :) It's a usability/security trade-off and I suppose it depends on how common the affected use case is: quite often, AppArmor policy can't reasonably support every single uncommon use case, as doing so would result in a mostly useless policy, while the vast majority of users would benefit from a stricter policy. If it feels like a safer default config to block such connections by default, then either we can keep things as-is, or silence the denial in the logs by adding the same lines prefixed with "deny "… at the cost of making it harder to debug and customize for folks who really need this. [capability] capabilities(7) Hoping it helps, cheers!
Bug#962530: [pkg-apparmor] Bug#962530: Tor service won't start when apparmor is active and "/" is on an overlayfs
Control: retitle -1 Improve support for rootfs-on-overlayfs systems Control: severity -1 wishlist Control: tag -1 + upstream Hi, Sorry for the delay! Stefan Baur (2020-06-16): > So if it's hard to get apparmor and overlayfs to play along nicely, > maybe the check shouldn't be for a Debian Live environment but more > generally for an environment that has its root file system mounted via > overlayfs? To avoid breaking existing installs of that kind, it should > probably print a warning to syslog instead of disabling apparmor completely. > [...] > On apparmor install/startup, check for an overlay mount, and if it is > present, warn the user that they may need to change/add paths in their > apparmor profiles? For the record, I don't plan to work on this myself. The general problem at hand is not specific to Debian, so I encourage folks who would like to work on this to discuss it on the upstream AppArmor mailing list: who knows, perhaps another distro has a solution already :) Cheers!
Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile
Control: tag -1 + wontfix Hi, … and sorry for the delay. Mikhail Morfikov (2020-10-24): > There are three ways of installing apparmor profiles in debian: > - an app's package contains some apparmor profile > - some packages contain lots of apparmor profiles > - there are a few packages which contain an app's apparmor profile itself, > for > instance fwknop-apparmor-profile > > So it's a mess. I understand this can be very confusing (I hope that's what you mean, expressed in terms of resulting impact, rather than in a judgmental manner). It's not news to me and I'm not surprised. In particular, the status of profiles shipped in the apparmor-profiles package often confuses folks (understandably!). As a result, the workload this package has required from me in the last years is disproportionately big, compared to its actual usefulness. I've tried to improve this in Bullseye by clarifying the package description, and including a reportbug script that asks users to report bugs upstream. If this is not enough to make users' expectations match our intent, or not enough to lower that workload, then I plan to stop maintaining the apparmor-profiles binary package in Debian myself. > It would be nice to have profiles in individual packages, so users > could decide what they want to install. Thanks for clarifying what use case is currently poorly supported. It seems to me that we want to optimize the user experience for different categories of users. The category of users I am primarily thinking about, when working on AppArmor support in Debian, are those who may not even know what AppArmor is, could not care less about whether profile X or Y is enforced, and certainly won't decide which profiles they want to install. I believe these are the vast majority of Debian users (and if that's not the case yet, then I prefer to work towards making this real). I'm happy to welcome contributions that improve UX for other categories of users, if this does not imply regressions for the aforementioned category. It does not look like your initial proposal achieves this, but perhaps a different proposal would :) >> Apart of this, the way the Debian archive works, having many tiny >> packages is problematic, so I don't think your proposal would be >> acceptable by the project. I'm not closing this bug report just yet as >> I'd like to first better understand what the current setup is lacking >> for you. > BTW: Why having many small packages is a problem for debian archive? This has been discussed several times on debian-devel@ so the answer can probably be found there. Cheers!
Bug#934735: [pkg-apparmor] Bug#934735: Bug#934735: dh-apparmor: please improve dh integration
Hi, intrigeri (2019-12-11): > Could you please describe what problem this solution would solve? > One way to explain this could be to show us how you envision this > improved integration would be used in a package, compared to the > status quo. Ping? :)
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi, First, I'm wondering if this bug might be related to the problem you recently fixed in debci's LXC containers AppArmor configuration. What about giving it another try? If that's not enough, then I'd like to come back to what we discussed a few months ago: intrigeri (2020-10-27): > Paul Gevers (2020-10-25): >> On 25-10-2020 19:44, intrigeri wrote: >>>>> Is there a better way for me to investigate? >>> >>>> We have given DD's temporarily access to one of our workers before. If >>>> you're interested we could do that again for this case. That way you >>>> could even skip the upload to experimental, assuming it reproduces if >>>> run from a local tree. And you can check what's going on in the test bed. >>> >>> This looks great. I'd like to do this once the updated baseline is >>> established, if it still fails. I could book time for this on Nov >>> 28-29. >> >> Can you can already point me at your public key? Easiest is with a >> signed e-mail, but if it's otherwise easily traceable it's from you, I >> can take it from elsewhere. > > Sure, will do right away in a private email. It seems I failed to follow up on this, sorry! I suppose it'll be easier to coordinate this via IRC (although I don't have a permanently-connected client). Cheers!
Bug#899616: Getting hunspell-ar and myspell-fa back into testing
Hi, do you plan to fix #899539 and #899616 soon? I could not find updates nor any repo on Salsa. These bugs caused these two packages to be removed from testing, which makes it harder e.g. for derivatives (such as Tails) that try to start working on their migration to Debian Buster, which is why these problems appeared on my radar. If you lack time to take care of it yourself soon, I can offer to NMU these packages in order to set the maintainer address to person listed in the Uploaders field who did most of the recent uploads. This would be a temporary stop-gap allowing the packages to migrate back into testing, until your team has had time to find out how you want to fix this. Just let me know :) Cheers, -- intrigeri
Bug#899958: Getting ibus-anthy and ibus-pinyin back into testing
Hi, do you plan to fix #899958 and #899538 soon? I could not find updates nor any Git repo on Salsa. These bugs caused ibus-anthy and ibus-pinyin to be removed from testing, which makes it harder e.g. for derivatives (such as Tails) that try to start working on their migration to Debian Buster, which is why these problems appeared on my radar. If you lack time to take care of it yourself soon, I can offer to NMU these packages in order to set the maintainer address to person listed in the Uploaders field who did most of the recent uploads. Just let me know :) Cheers, -- intrigeri
Bug#898085: gnupg: gpg --search-keys and parcimonie don't work: Tor misconfigured/keyserver EPERM
Control: reassign -1 parcimonie Control: tag -1 + moreinfo Hi, I believe that for the time being, this problem cannot be fixed in GnuPG but rather in parcimonie. Cyril Brulebois: > Ever since the dist-upgrade to stretch (last september), I'm unable to > search keys, and parcimonie is failing on me: > | kibi@armor:~$ gpg --search-keys some@mail.address > | gpg: WARNING: Tor is not properly configured > | gpg: error searching keyserver: Permission denied > | gpg: keyserver search failed: Permission denied May I assume that you have no tor service running? parcimonie enables the use-tor option in ~/.gnupg/dirmngr.conf. It's being debated on another bug report (filed against parcimonie) whether it's a feature or a bug, and if the latter how to fix it. Anyway: currently, as soon as parcimonie has been run once as a given user, then any dirmngr network operation run as that user require a working tor daemon. Now, parcimonie merely "Recommends: tor" (since 2011). I don't recall why I did not add a strict dependency back then; possibly I wanted to be nice to Tor Browser users who don't want to run a system tor, and instead use the tor that comes bundled with Tor Browser (there are good reasons for setting things up like this, such as having a single place to configure bridges etc. and being able to do so in a GUI). So, in some way a Recommends is correct: one of the major use cases of parcimonie works just fine without Debian's tor service (using 3rd-party software though). OTOH, parcimonie will simply be broken for whoever has disabled installation of Recommends by default, unless they know exactly that they want to run tor in a different way, and how to do so. So there's a case to be made to turn this "Recommends: tor" into "Depends: tor". > How come gpg fails this badly in stable, with a default configuration? I think the default gpg configuration in stable works fine… as long as one is not unlucky enough to meet all these conditions: - having disabled installation of Recommends by default (or manually de-installed tor, or manually disabled the tor service) - not running Tor Browser - having installed parcimonie Cheers, -- intrigeri
Bug#898085: gnupg: gpg --search-keys and parcimonie don't work: Tor misconfigured/keyserver EPERM
Cyril Brulebois: > intrigeri (2018-06-30): >> May I assume that you have no tor service running? > Well: > kibi@armor:~$ gpg --search-keys k...@mraw.org > gpg: WARNING: Tor is not properly configured > gpg: error searching keyserver: Permission denied > gpg: keyserver search failed: Permission denied > kibi@armor:~$ ps faux|grep tor > debian-+ 895 0.0 0.2 89636 38352 ? Ss Jun23 8:52 /usr/bin/tor > --defaults-torrc > /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 Thanks for the prompt reply! OK, so it looks I was wrong to reassign to parcimonie. Before I draw conclusions, I need a little bit more info: - Can you please check that tor listens on 127.0.0.1:9050 (TCP)? - Does "torsocks curl https://www.debian.org/"; work fine? - Could you please share your ~/.gnupg/dirmngr.conf and ~/.gnupg/gpg.conf with me (possibly privately)? > I'm not sure I'm ticking all these boxes… Indeed. Cheers, -- intrigeri
Bug#900388: parcimonie: systemd user journal bloat: parcimonie.desktop[]: gpg: key "" not found: Not found
hi Paul, Paul Wise: > I noticed that parcimonie bloats the systemd user journal with lots of > fingerprints of keys that could not be found. On spinning rust with a > large keyring this is a significant amount of I/O bandwidth, extra disk > space usage and a noticeable amount of journald and rsyslog CPU usage. > There is no reason for parcimonie to be logging not found keys, since > having keys in one's keyring that are not on the public keyservers is > a legitimate use-case that parcimonie users are likely to be doing. Agreed. I'm testing a tentative fix as we speak. Cheers, -- intrigeri
Bug#883584: closed by intrigeri (Bug#883584: fixed in apparmor 2.13-1)
Control: notfixed -1 2.13-1 Control: found -1 2.13-1 Control: found -1 2.13-2 Control: tag -1 - upstream I got it wrong. Tentatively fixed on the debian/experimental branch, will test before uploading 2.13-3 (probably to sid and probably during DebCamp).
Bug#901471: thunderbird: AppArmor denies access to ~/.cache/mesa_shader_cache/index after recent Mesa update
Vincas Dargis: > I am proposing new abstraction for Mesa libraries: > https://gitlab.com/apparmor/apparmor/merge_requests/137 > Once it's in, I'll backport needed changes to Thunderbird profile. Vincas did that, then I've reviewed'n'merged that upstream and pushed to Vcs-Git.
Bug#901471: Thunderbird should not be able to render the xserver unusable
Hi Eric, Erich Schubert: > I am unsure where to clone the issue. > For obvious reasons, a client application like thunderbird should not be able > to > break the xserver in a way that thunderbird does. > While extending the apparmor permissions makes thunderbird work again (and > thus > solves this bug), there is an underlying issue with the xserver most likely. > When I try to use thunderbird with apparmor enabled, the xserver stops > drawing except > for the mouse cursor; and even killing the thunderbird process does not fix > the > xserver. That should be prevented on the xserver side. Very good point, I wholeheartedly agree. But I suspect you've followed up on the wrong bug: I can see no indication that #901471 caused this much trouble. Maybe you're talking about #900840 or one of its numerous clones? I'm not sure where that problem should be tracked either. Perhaps you could ask debia...@lists.debian.org? FWIW I've not been affected by this bug on GNOME Wayland. Cheers, -- intrigeri
Bug#898085: gnupg: gpg --search-keys and parcimonie don't work: Tor misconfigured/keyserver EPERM
Hi, I've tested this in a clean Stretch VM. I've added these lines to ~/.gnupg/dirmngr.conf in order to get more info: verbose debug 1024 And what I see when searching for my key is: Jul 08 05:57:22 debian systemd[1022]: Started GnuPG network certificate management daemon. Jul 08 05:57:22 debian dirmngr[2574]: dirmngr[2574]: enabled debug flags: ipc Jul 08 05:57:22 debian dirmngr[2574]: dirmngr[2574]: error opening '/home/toto/.gnupg/dirmngr_ldapservers.conf': No such file or directory Jul 08 05:57:22 debian dirmngr[2574]: permanently loaded certificates: 0 Jul 08 05:57:22 debian dirmngr[2574]: runtime cached certificates: 0 Jul 08 05:57:22 debian dirmngr[2574]: handler for fd 5 started Jul 08 05:57:22 debian dirmngr[2574]: DBG: chan_5 -> # Home: /home/toto/.gnupg Jul 08 05:57:22 debian dirmngr[2574]: DBG: chan_5 -> # Config: /home/toto/.gnupg/dirmngr.conf Jul 08 05:57:22 debian dirmngr[2574]: DBG: chan_5 -> OK Dirmngr 2.1.18 at your service Jul 08 05:57:22 debian dirmngr[2574]: connection from process 2573 (1000:1000) Jul 08 05:57:22 debian dirmngr[2574]: DBG: chan_5 <- GETINFO version Jul 08 05:57:22 debian dirmngr[2574]: DBG: chan_5 -> D 2.1.18 Jul 08 05:57:22 debian dirmngr[2574]: DBG: chan_5 -> OK Jul 08 05:57:22 debian dirmngr[2574]: DBG: chan_5 <- KS_SEARCH -- intrig...@debian.org Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2600:1f16:41e:bd0a::73:6b73]' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '216.66.15.2' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '192.146.137.11' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '68.187.0.77' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '51.15.53.138' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '37.191.226.104' Jul 08 05:57:24 debian dirmngr[2574]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': '18.191.65.131' Jul 08 05:57:24 debian dirmngr[2574]: can't connect to '2001:bc8:4700:2300::10:f15': Permission denied Jul 08 05:57:24 debian dirmngr[2574]: error connecting to 'https://[2001:bc8:4700:2300::10:f15]:443': Permission denied Jul 08 05:57:24 debian dirmngr[2574]: (Tor configuration problem) Jul 08 05:57:24 debian dirmngr[2574]: DBG: chan_5 -> S WARNING tor_config_problem 0 Please check that the "SocksPort" flag "IPv6Traffic" is set in torrc Jul 08 05:57:24 debian dirmngr[2574]: command 'KS_SEARCH' failed: Permission denied Jul 08 05:57:24 debian dirmngr[2574]: DBG: chan_5 -> ERR 167804929 Permission denied Jul 08 05:57:24 debian dirmngr[2574]: DBG: chan_5 <- BYE Jul 08 05:57:24 debian dirmngr[2574]: DBG: chan_5 -> OK closing connection Jul 08 05:57:24 debian dirmngr[2574]: handler for fd 5 terminated So indeed, the default GnuPG configuration in Stretch cannot work out of the box once "use-tor" is enabled. One needs to: - either specify a keyserver whose hostname won't resolve to IPv6, like: echo 'keyserver hkp://jirk5u4osbsr34t5.onion' \ >> ~/.gnupg/dirmngr.conf - or edit /etc/tor/torrc to enable the "IPv6Traffic" flag for the "SocksPort" that's used by dirmngr, i.e. something along the lines of: echo 'SocksPort 9050 IPv6Traffic' | sudo tee -a /etc/tor/torrc && \ sudo systemctl restart tor@default Can you please confirm that one of those fixes the problem you're facing? I'm sure I've noticed this problem before and we've discussed it already, either with dkg or weasel, and I hope it's well tracked somewhere. I'll check and will then adjust BTS metadata accordingly. Cheers, -- intrigeri
Bug#898085: gnupg: gpg --search-keys and parcimonie don't work: Tor misconfigured/keyserver EPERM
Control: reassign -1 dirmngr
Control: found -1 2.1.18-8~deb9u1
Control: found -1 2.1.18-8~deb9u2
Control: fixed -1 2.2.8-3
Hi,
intrigeri:
> I'm sure I've noticed this problem before and we've discussed it
> already, either with dkg or weasel, and I hope it's well tracked
> somewhere. I'll check and will then adjust BTS metadata accordingly.
FTR that was #849845, whose resolution was twofold:
- tor now enables IPv6 traffic on the SocksPort by default
(in stretch-backports and Buster)
- if IPv6 traffic is not enabled, dirmngr now tells the user what the
problem is and how to fix it (not sure in which version but
definitely in the Buster one)
On the parcimonie side of things, I've updated the manpage so that
setup instructions that should now cover most common cases. This will
be part of the upcoming 0.10.4 but of course that won't help
Stretch users.
This bug is clearly not in parcimonie, but in dirmngr: parcimonie
"just" triggers it 100% of the time on a default Stretch installation.
So I'm reassigning to dirmngr. I'd like to treat this bug report as
one about the UX with the default config in Stretch (while #849845 was
about how to fix the root cause of the problem in tor) but that it
does not affect Buster (thanks to the default Tor config change).
The thing is, the UX improvements mentioned on
https://dev.gnupg.org/T2902 *are* in Stretch:
- dirmngr tells "Tor is not properly configured"
- with --verbose, I see:
gpg: (further info: Please check that the "SocksPort" flag "IPv6Traffic" is
set in torrc)
… but honestly that does not seem good enough to me:
- Quite simply, the fact someone like Cyril did not get what was
going on, and that it took me some time to diagnose the problem,
is quite telling in itself.
- The fact that one needs to pass --verbose to have any clue what is
going on is worrying: in a situation where the user is told
something that's hard to understand already ("Tor is not properly
configured", while Tor works just fine for most practical
purposes), they should not have to guess yet they have to manually
do another thing in order to be told what exactly is wrong with the
tor configuration. I would suggest the IPv6Traffic hint is
displayed by default on Stretch, and not guarded behind --verbose.
On Buster and newer, IMO we can stick to what upstream does since
the default Tor configuration was fixed, so this UX problem should
be moot :)
Dear GnuPG maintainers, feel free to merge with #849845, adjust the
metadata as you wish, and possibly improve the UX in Stretch by
implementing the suggestion above or something better.
Or just call it something that won't affect enough Stretch users to
warrant a s-p-u and then wontfix, your call :)
Cheers,
--
intrigeri
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
Hi, intrigeri (2021-01-08): > Christian Boltz (2021-01-07): >> I'd argue that this is a problem that is already solved ;-) >> >> Starting with AppArmor 3.0, all[1] upstream abstractions come with a >> rule like (example taken from abstractions/base): >> >> include if exists >> >> so if you create that directory and place a file there, it will be >> included by the abstraction. > >> [...] > >> For abstractions shipped by individual package (like libvirt), it would >> also make sense to add an include if exists >> rule to make it easy to add something to an abstraction. > > I like what Christian Boltz is proposing (thanks!): as far as > I understand, it can happen in libvirt upstream, will benefit even > non-Debian distros, and does not require modifying dh-apparmor. > > Christian Ehrhardt, how does it sound? Any reason why the approach you > initially suggested on this bug report is better? Ping? I'd like to add that one of the reasons for adding support for "include if exists" in AppArmor upstream was to cancel the need for distros to manage local override files via packaging machinery, which long term will allow us to simplify things like dh-apparmor, making them easier to maintain and to use :)
Bug#876647: Provide facility to reload a profile when included snippets shipped by other packages are added/updated/removed
See also https://bugs.debian.org/872266, which is also about policy that confine programs shipped in other packages.
Bug#876647: dh-apparmor: Please support /etc/apparmor.d/apache
Control: retitle -1 Provide facility to reload a profile when included snippets shipped by other packages are added/updated/removed Hi, FTR, there's no real-world example in testing anymore of the exact use case why this was requested initially: - kopano-webapp was orphaned, removed from testing, and it's unlikely to come back any time soon. - We don't ship usr.lib.apache2.mpm-prefork.apache2 anymore. But: - We still ship usr.sbin.apache2 with "#include ". - It's no surprise that other packages don't do this sort of things, given it's not well supported by our packaging machinery. So I'm generalizing this bug report. Notes to whoever will work on this: - To me it screams "dpkg triggers", since they provide the kind of facility we need here, i.e. ensure package X is informed it shall do something whenever package Y is installed/updated/removed. In the example at hand, libapache2-mod-apparmor would be triggered and would reload the usr.sbin.apache2 profile, whenever a package adds/updates/removes bits in /etc/apparmor.d/apache2.d/. - I think the right thing to do depends on how the plugin integration is done wrt. non-AppArmor aspects. For example, if adding/updating/removing a plugin package does *not* restart the affected program, then I think we should not reload the AppArmor policy either: otherwise, we would confine an older, already running, version of the code, with a new version of the AppArmor policy, and they may very well be incompatible. Cheers!
Bug#934735: dh-apparmor: please improve dh integration
Control: tag -1 - moreinfo Heya, High-level note: I lack knowledge to evaluate this proposal in terms of debhelper integration. I'd be grateful if Niels could take a look :) Andrej Shadura (2021-02-05): > I’ll start with explaining the idea. Awesome, thanks, it helps a lot! > The status quo is: > * Each profile needs to be installed manually > * dh_apparmor needs to be told which profiles to use > * dh_apparmor needs to be told to only run on specific packages > * override_* or execute_after_* are mandatory We're on the same page here. More generally, it is seriously sub-optimal that using dh_apparmor requires programming, as opposed to using a declarative syntax (for non-obvious cases) and auto-detection (for obvious cases). > My proposal is: > * For dh compat level <= 13: > - allow running dh_apparmor without arguments; > - without arguments, scan binary packages for apparmor profiles and use > their names automatically > - dh_apparmor can be enabled with --with=apparmor or B-D: > dh-sequence-apparmor > - without arguments, dh_apparmor only generates maintainer scripts for > packages with apparmor profiles > - with arguments, dh_apparmor does everything like it does now, no changes > > * For dh compat level 14: > - as above, but with arguments, only generate maintainer scripts for the > corresponding binary packages > The above will allow processing apparmor profiles without extra > rules in d/rules, while maintaining compatibility with > existing packages. I understand that at a higher level, for the simplest cases this translates into something like this: As a maintainer When I ship an AppArmor profile in a binary package And I enable the dh_apparmor debhelper sequence Then the dh_apparmor machinery Does The Right Thing™ without further configuration As a maintainer, I think it's awesome! It may be worth specifying behavior for one corner case: what happens if a "-p PACKAGE" argument is passed? Possible improvements for further iterations, definitely not blocking this plan IMO, i.e. food for future thought: - Either drop support for --profile-name or, if for some reason it's still needed, support declarative syntax to configure it. - Consider enabling dh_apparmor by default (and provide means to disable it, either entirely or on a per-profile basis with declarative syntax). Cheers!
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi Paul, Paul Gevers (2021-02-05): > On 05-02-2021 18:02, intrigeri wrote: >> First, I'm wondering if this bug might be related to the problem you >> recently fixed in debci's LXC containers AppArmor configuration. > > That was only on one particular ppc64el host, so that shouldn't impact > the other architectures. Ah, right :) >> What about giving it another try? > > After the above, does that really make sense? Not at all. > I'll give further instructions in private. Thanks!
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi, I've just run the src:apparmor autopkgtests on ci-worker05 a bunch of times, using the autopkgtest command: - from an unpacked source tree: - experimental (3.0.1-4): 5 times - unstable (2.13.6-8): 3 times - using the package that's in the archive: - experimental (3.0.1-4): 2 times - unstable (2.13.6-8): 2 times - Buster (2.13.2-10): 2 times Every time, the test succeeded, then the autopkgtest command exited immediately, and the LXC container was promptly stopped and destroyed. IOW, I was not able to reproduce the bug. So either I've been incredibly lucky, or the bug has already been fixed somehow, or the bug is only triggered when the autopkgtest is started by the debci worker service. Any idea on how to proceed from here? I suppose someone would have to be logged into the relevant worker when the bug happens, in order to investigate further. OTOH it's also tempting to wait until you upgrade the ci.d.n infra to Bullseye and come back to it at that point, especially if there's a simple short-term mitigation: Paul Gevers wrote: > Something in the test is very often preventing autopkgtest (the > binary) from stopping and cleaning up the lxc container within the > 600 seconds it gets to do that, which leads to a tmpfail for the > apparmor autopkgtest and a still running lxc container on the > worker. […] Your autopkgtest itself normally passes before causing > the issue. I understand the LXC container is stopped and restarted between each test, so what Paul wrote above suggests the container is successfully stopped between the 1st and 2nd test, same between the 2nd and 3rd test, but then it occasionally fails to stop after the last (3rd) test. Correct? If this analysis is correct, then the culprit has to be in the 3rd test i.e.: # Dummy test so that changes to linux-image-amd64 trigger our other autopkgtests # on ci.debian.net Test-Command: /bin/true Depends: linux-image-amd64 [amd64] | linux-image-generic [ amd64 ] Restrictions: superficial, skip-not-installable … and this is the one I should mark it as isolation-machine, so we can resume running the other 2 tests on ci.d.n, which I would very much like. Makes sense? Cheers!
Bug#934735: [pkg-apparmor] Bug#934735: dh-apparmor: please improve dh integration
Hi, thanks for the quick answer. For now I'll focus on Andrej's plans (not potential future improvements) and the bits I know best, leaving it to Andrej to reply about the other aspects :) Niels Thykier (2021-02-06): > intrigeri: > As I read dh_apparmor, it generates maintscript based on the > --profile-name parameter. That name must match a file installed > in /etc/apparmor.d (of same name). This implies that something else > have (or will) install the actual file into /etc/apparmor.d. > > => Is this correctly understood? Right. >> Possible improvements for further iterations, definitely not blocking >> this plan IMO, i.e. food for future thought: >> >> - Either drop support for --profile-name or, if for some reason it's >>still needed, support declarative syntax to configure it. >> > > What about manifests? We can have them declarative by providing them in > a "guessible" location (e.g. debian/apparmor-manifests/ would match > debian/.../etc/apparmor.d/). But that implies that "omission" > (including accidental) is silently accepted as "no manifest". > I do not know the consequence of that, so I cannot say if this > approach is good or not. FTR, I've not found any trace of a package in the archive using the --manifest=manifestfile facility. > Accordingly, I am not going to take a decision in the near future > about whether dh_apparmor should be enabled by default via debhelper > itself. Fully agreed, this was merely food for thought for potential future iterations :)
Bug#982436: procps: Please allow overriding protect-links.conf settings via /etc/sysctl.conf
Package: procps Version: 2:3.3.17-1 Severity: normal X-Debbugs-Cc: none Hi, I have set fs.protected_fifos=2 in /etc/sysctl.conf. My intent is to override procps' protect-links.conf, which sets fs.protected_fifos=1. Under systemd, /etc/sysctl.conf is actually loaded via the /etc/sysctl.d/99-sysctl.conf symlink, which sorts before protect-links.conf, so the distro setting from protect-links.conf overrides the custom value I've set in /etc/sysctl.conf. I find this counter-intuitive: I would expect whatever I write in /etc/sysctl.conf to override distro defaults. This has historically been the case, and at least one system management tool I'm using (a Puppet module) operates under the same assumption. I understand this assumption still works fine in every other case in Debian, because: - The name of the /etc/sysctl.d/99-sysctl.conf symlink starts with "99", which should sort last if all other such *.conf files have names that start with NN < 99. - All other packages that ship files in /usr/lib/sysctl.d/ call these files NN-*.conf, with N < 99. The only exception in the archive is procps, which does not use such a numeric prefix, and thus makes this assumption incorrect wrt. the contents of protect-links.conf. Would you mind renaming protect-links.conf to NN-protect-links.conf, with NN < 99? Thanks for maintaining procps, and thanks in advance for considering my request :) Cheers! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (2, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.60 ii libc62.31-9 ii libncurses6 6.2+20201114-2 ii libncursesw6 6.2+20201114-2 ii libprocps8 2:3.3.17-1 ii libtinfo66.2+20201114-2 ii lsb-base 11.1.0 Versions of packages procps recommends: ii psmisc 23.4-2 procps suggests no packages.
Bug#923500: snapd: non-classic snap not confined
Hi, James Henstridge (2021-02-16): > 2. As for why Debian is not being considered for "full" support, > I suspect this is down to the out-of-tree patches to enable access > control for unix domain sockets. This will likely resolve itself > when snapd moves to use the new AppArmor 3.0 network features (which > does not rely on out of tree patches). FTR, according to Jamie Strandboge [1], even with AppArmor 3 some network features are missing until support is added to the upstream kernel: Jamie Strandboge (Mon, 5 Oct 2020 12:42:50 -0500): > AppArmor 3 allows use of networkv8 rules (ie, what is in the upstream > kernel) so apparmor 3 in Debian would allow for this to work. > > The upstream kernel does not yet support AF_UNIX rules, so anonymous > sockets, abstract sockets and dbus won't be available. Work has picked > up to get this into the upstream kernel (perhaps 5.11). [1] https://bugs.debian.org/712451#126 Cheers!
Bug#983006: apt-cacher-ng apparmor profile denies access to /proc/sys/kernel/random/uuid which is read during restarts
Control: tag -1 + patch Control: tag -1 + upstream Control: forwarded -1 https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/48 Hi Paul, Thanks for this amazing bug report! I've send a merge request upstream and will upload to sid shortly. Cheers!
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi, intrigeri (2021-02-06): > I understand the LXC container is stopped and restarted between each > test, so what Paul wrote above suggests the container is successfully > stopped between the 1st and 2nd test, same between the 2nd and 3rd > test, but then it occasionally fails to stop after the last > (3rd) test. Correct? > > If this analysis is correct, then the culprit has to be in the 3rd > test i.e.: > > # Dummy test so that changes to linux-image-amd64 trigger our other > autopkgtests > # on ci.debian.net > Test-Command: /bin/true > Depends: linux-image-amd64 [amd64] | linux-image-generic [ amd64 ] > Restrictions: superficial, skip-not-installable > > … and this is the one I should mark it as isolation-machine, > so we can resume running the other 2 tests on ci.d.n, > which I would very much like. > > Makes sense? Actually, apparmor-profiles-extra has the exact same test, and AFAICT it seems to run pretty reliably there, so I now have doubts about the hypothesis I quoted above. Still, perhaps it's worth trying to add isolation-machine to that test, remove src:apparmor from the blocklist, and see what happens? Cheers!
Bug#982436: procps: Please allow overriding protect-links.conf settings via /etc/sysctl.conf
Hi Craig, Craig Small (2021-02-15): > Are you sure you are still seeing this in 3.3.17? The directory orders > got changed around in that release so it might be fixed already. > > $ strace sysctl --system 2>&1 | egrep 'openat.*(etc|lib)/sys' > [...] > > /etc/sysctl.conf is read after /usr/lib/sysctl.d/protect-links.conf > That's what you wanted right? > > [...] > > root@floyd:~# /sbin/sysctl --system > [...] > ** Applying /usr/lib/sysctl.d/protect-links.conf *... > *fs.protected_fifos = 1* > fs.protected_hardlinks = 1 > fs.protected_regular = 2 > fs.protected_symlinks = 1 > * *Applying /etc/sysctl.conf* ... > net.ipv6.conf.all.accept_redirects = 0 > net.ipv6.conf.default.accept_redirects = 0 > *fs.protected_fifos = 2* > > root@floyd:~# sysctl fs.protected_fifos > f*s.protected_fifos = 2* I confirm this problem does not happen when I use "sysctl --system". However, this problem does happen with procps 2:3.3.17-4 after a reboot (or more simply, after restarting procps.service). My understanding is that when using systemd, what matters is what systemd-sysctl does, not what "sysctl --system" does: procps.service is a symlink to systemd-sysctl.service, which calls systemd-sysctl and not "sysctl --service". So, in order to solve this bug on Debian systems that use systemd, one needs to do either one of: a) Modify the behavior of systemd-sysctl so it matches the current behavior of "sysctl --system". I don't know how realistic this is. b) Rename protect-links.conf as I suggested, so it integrates more nicely with the configuration system it's de facto primarily meant for nowadays. Does this make sense? Sorry if I totally misunderstood or missed something! Cheers, -- intrigeri
Bug#973356: [pkg-apparmor] Bug#973356: apparmor-profiles: complain on syslog-ng opening system.journal until re-enabling profile
Control: severity -1 minor Hi, I'm lowering severity, in line with the description of the package: apparmor-profiles provides various experimental AppArmor profiles. Do not expect these profiles to work out-of-the-box. . These profiles are not mature enough to be shipped in enforce mode by default on Debian. They are shipped in complain mode so that users can test them, choose which are desired, and help improve them upstream if needed. … and also because this profile is not enforced by default, and this bug report is about a heavily customized setup that an distro-shipped AppArmor profile is unlikely to ever support by default. Cheers!
Bug#977896: ITP: metadata-cleaner -- View and remove metadata in files
Hi, > I would like to maintain this program Awesome, thanks! > and am searching for a sponsor. I suggest you get in touch with the maintainers of MAT2 in Debian: https://tracker.debian.org/pkg/mat2 They might be happy to sponsor uploads of your work, and perhaps even to collaboratively maintain this package together with you under the umbrella of their team :) Cheers!
Bug#972387: mtools: does not work in Turkish locale
Package: mtools Version: 4.0.24-1 Severity: important User: tails-...@boum.org Usertags: localization Hi! $ LC_CTYPE=tr_TR.UTF-8 mtools Syntax error at line 5 for drive A: column 9 in file /etc/mtools.conf: unrecognized keyword $ echo $? 1 $ LC_CTYPE=C mtools Supported commands: mattrib, mbadblocks, mcat, mcd, mclasserase, mcopy, mdel, mdeltree mdir, mdoctorfat, mdu, mformat, minfo, mlabel, mmd, mmount mpartition, mrd, mread, mmove, mren, mshowfat, mshortname, mtoolstest mtype, mwrite, mzip mtools.conf is the default one (MD5 = 659bb18a4490dcb17ad0b0139c2fb654). https://bugs.launchpad.net/ubuntu/+source/mtools/+bug/1479152 has a plausible explanation. But I don't understand why that bug report is marked as "Fix released" in since they don't appear to patch this package. Cheers! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (2, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mtools depends on: ii libc6 2.31-4 mtools recommends no packages. Versions of packages mtools suggests: pn floppyd -- no debconf information
Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile
Control: tag -1 + moreinfo Hi, Mikhail Morfikov (2020-07-20): > currently when the apparmor-profiles package is installed, it installs several > apparmor profile files. In this way users can have all or none of the profiles > installed in their systems. Sometimes a user wants only a specific profile (or > profiles) installed and doesn't really want the other profiles to be installed > as well because: > - he doesn't need the other profiles, > - he has his own alternative profiles, which differ in rule sets, > - the other profiles simply cause some issues with applications they confine. > What do you think about another approach, which is to create separate packages > containing individual apparmor profiles? For instance, there's the > usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case > there could be a package named dnsmasq-apparmor-profile which would include > the > usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it > to be confined by the default apparmor profile provided by Debian, he could > also install dnsmasq-apparmor-profile, which wouldn't affect any other app > functionality. The profiles shipped by the apparmor-profiles package are installed in complain mode. Then the user may choose to enforce the profiles they need. To me, it seems to already provide the kind of flexibility you're wishing for, with a much lower overhead on the package maintenance side. What did I miss? Apart of this, the way the Debian archive works, having many tiny packages is problematic, so I don't think your proposal would be acceptable by the project. I'm not closing this bug report just yet as I'd like to first better understand what the current setup is lacking for you. Cheers!
Bug#969114: apparmor-profiles: usr.sbin.dovecot does not allow reading /usr/share/dovecot/dh.pem (dovecot fails to start)
Hi Vincas! Vincas Dargis (2020-08-27): > This is produced if usr.sbin.dovecot is copied to /etc/apparmor.d: > > ``` > type=AVC msg=audit(1598556536.092:901): apparmor="DENIED" operation="open" > profile="dovecot" name="/usr/share/dovecot/dh.pem" pid=12625 comm="doveconf" > requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > ``` > > This results in dovecot failing to start: > > ``` > Aug 27 22:31:47 systemd[1]: Started Dovecot IMAP/POP3 email server. > Aug 27 22:31:47 dovecot[13693]: doveconf: Fatal: Error in configuration file > /etc/dovecot/conf.d/10-ssl.conf line 50: ssl_dh: Can't open file > /usr/share/dove > Aug 27 22:31:47 systemd[1]: dovecot.service: Main process exited, > code=exited, status=89/n/a > Aug 27 22:31:47 systemd[1]: dovecot.service: Failed with result 'exit-code'. > ``` > > It is fixed by adding single rule: > > ``` > /usr/share/dovecot/dh.pem r, > ``` Do you think it's too Debian-specific to fix upstream? Cheers!
Bug#968607: pidgin-openpgp: AppArmor profil prevents execution of XEP-0027.pl
Control: tag -1 + pending Hi, Henning Follmann (2020-08-18): > On start of pidgin I get this error: > Can't locate strict.pm: /usr/share/perl/5.28/strict.pm: Permission denied > at /usr/lib/purple-2/XEP-0027.pl line 31. > BEGIN failed--compilation aborted at /usr/lib/purple-2/XEP-0027.pl line 31. > > Journalctl info: > Aug 18 09:58:17 typer audit[2790]: AVC apparmor="DENIED" operation="open" > profile="/usr/bin/pidgin" name="/usr/share/perl/5.28.1/strict.pm" pid=2790 > comm= > Aug 18 09:58:17 typer kernel: audit: type=1400 audit(1597759097.069:42): > apparmor="DENIED" operation="open" profile="/usr/bin/pidgin" > name="/usr/share/per Given pidgin-openpgp was removed from testing and sid, IMO it's not worth adding support for it in the AppArmor profile, so let's instead ensure the obsolete pidgin-openpgp package gets removed if apparmor-profiles-extra is installed: https://salsa.debian.org/apparmor-team/apparmor-profiles-extra/-/commit/eedb248ece01e65ce5572f5cc0b1a59c1bfc8f06 Cheers!
Bug#968951: [pkg-apparmor] Bug#968951: apparmor-profiles: Profile incomplete for pidgin and telepathy
Control: reassign -1 telepathy-mission-control-5 Control: retitle -1 AppArmor profile conflicts with pidgin-openpgp Hi, Henning Follmann (2020-08-24): > When you try to login to a jabber server either via empathy or pidgin > /usr/lib/purple-2/XEP-0027.pl will be called but fails because of an > incomplete AppArmor profile: > > Aug 06 19:55:20 typer audit[4039]: AVC apparmor="DENIED" operation="open" > profile="/usr/lib/telepathy/telepathy-*" > name="/usr/share/perl/5.28.1/strict.pm" > +pid=4039 comm="telepathy-haze" requested_mask="r" denied > Aug 06 19:55:20 typer org.freedesktop.Telepathy.ConnectionManager.haze[3320]: > Can't locate strict.pm: /usr/share/perl/5.28/strict.pm: Permission denied at > +/usr/lib/purple-2/XEP-0027.pl line 31. > Aug 06 19:55:20 typer org.freedesktop.Telepathy.ConnectionManager.haze[3320]: > BEGIN failed--compilation aborted at /usr/lib/purple-2/XEP-0027.pl line 31. > Aug 06 19:55:20 typer kernel: audit: type=1400 audit(1596758120.240:27): > apparmor="DENIED" operation="open" profile="/usr/lib/telepathy/telepathy-*" > +name="/usr/share/perl/5.28.1/strict.pm" pid=4039 comm="telepat Reassigning to the package that ships the telepathy profile. I suppose it's the same problem as for the usr.bin.pidgin profile, for which I did this: https://salsa.debian.org/apparmor-team/apparmor-profiles-extra/-/commit/eedb248ece01e65ce5572f5cc0b1a59c1bfc8f06 > or for pidgin > > Aug 18 09:58:17 typer audit[2790]: AVC apparmor="DENIED" operation="open" > profile="/usr/bin/pidgin" name="/usr/share/perl/5.28.1/strict.pm" pid=2790 > comm= > Aug 18 09:58:17 typer kernel: audit: type=1400 audit(1597759097.069:42): > apparmor="DENIED" operation="open" profile="/usr/bin/pidgin" > name="/usr/share/per The pidgin-openpgp part is tracked by https://bugs.debian.org/968607 so let's focus on Telepathy here. Cheers!
Bug#904732: autopkgtest-build-lxc doesn't work
Hi, Ben Hutchings (2018-07-27): > lxc-start: lxccontainer.c: wait_on_daemonized_start: 754 Received container > state "ABORTING" instead of "RUNNING" > lxc-start: tools/lxc_start.c: main: 368 The container failed to start. > lxc-start: tools/lxc_start.c: main: 370 To get more details, run the > container in foreground mode. > lxc-start: tools/lxc_start.c: main: 372 Additional information can be > obtained by setting the --logfile and --logpriority options. FWIW, I had the same problem, and it got fixed by starting lxc-net.service. I had /etc/default/lxc-net configured already for other reasons; I don't know if that's necessary here. Cheers!
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi, Paul Gevers (2020-05-25): > The most obvious alternative is that your run it locally, but I guess > you tried and couldn't reproduce? I usually use the libvirt backend but I tried today with the lxc backend locally, and could not reproduce. Note I don't see this problem on Salsa CI either. I took a closer look and the problem happens after successfully running the compile-policy test. I can't imagine how what this test does can interfere with shutting down the container, *but* that test installs a bunch of packages: apparmor, apparmor-profiles-extra, bind9, cups-browsed, cups-daemon, evince, haveged, kopano-dagent, kopano-server, libreoffice-common, libvirt-daemon-system, man-db, ntp, onioncircuits, tcpdump, tor I suspect one of those failed to stop within the 600s timeout in the ci.d.n environment. This being said, this was a while ago, and I wonder if the problem got somehow fixed in one of those packages in the meantime. Could you please give it another try with 2.13.5-1 (sid) or 3.0.0-1 (experimental), and ideally both? This would establish an updated baseline for further investigation. >> Is there a better way for me to investigate? > We have given DD's temporarily access to one of our workers before. If > you're interested we could do that again for this case. That way you > could even skip the upload to experimental, assuming it reproduces if > run from a local tree. And you can check what's going on in the test bed. This looks great. I'd like to do this once the updated baseline is established, if it still fails. I could book time for this on Nov 28-29. Cheers!
Bug#972887: libgstreamer1-perl: Deprecated upstream
Source: libgstreamer1-perl Severity: serious X-Debbugs-Cc: Mike Gabriel User: debian-p...@lists.debian.org Usertags: rm-candidate Hi, upstream announced¹ that the GStreamer Perl module would be deprecated and archived in December 2020: - The module will no longer be updated with security patches, bug fixes, or when changes are made in the Perl ABI. - It will no longer be possible to submit new issues or pull requests for these modules, or push new changes to their Git repos. Therefore, I don't think we should ship this package in Bullseye. Any objection to removing the package from testing & sid? This is a leaf package and popcon is 4/19 (vote/inst). [1] https://mail.gnome.org/archives/gtk-perl-list/2020-October/msg2.html
Bug#972888: libclutter-perl: Deprecated upstream
Source: libclutter-perl Severity: serious User: debian-p...@lists.debian.org Usertags: rm-candidate Hi, upstream announced¹ that the Clutter Perl module would be deprecated in December 2020. It is actually already archived on their GitLab, so: - The module will no longer be updated with security patches, bug fixes, or when changes are made in the Perl ABI. - It will no longer be possible to submit new issues or pull requests for these modules, or push new changes to their Git repos. Therefore, I don't think we should ship this package in Bullseye. Any objection to removing the package from testing & sid? This is a leaf package and popcon is 0/9 (vote/inst). [1] https://mail.gnome.org/archives/gtk-perl-list/2020-October/msg2.html
Bug#972887: libgstreamer1-perl: Deprecated upstream
Control: severity -1 normal Control: retitle -1 Inactive upstream Hi Mike, Mike Gabriel (2020-10-26): > I don't think that libgstreamer1-perl as found in Debian is the one > provided by GNOME/Gtk / referenced in the given URL / deprecation > announcement. You're right! This one is https://github.com/frezik/GStreamer1. The GNOME one, that I was referring to, was previously packaged as libgstreamer-perl (removed in 2015: #799327). Sorry for the confusion. Shall I close this bug? > Nonetheless, the upstream for libgstreamer1-perl has also been quite > inactive over the past years. > I will ping Perl people that I know if > they are interested in taking over upstream maintenance. Sounds great, thanks! :)
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi, Paul Gevers (2020-10-25): > On 25-10-2020 19:44, intrigeri wrote: >> This being said, this was a while ago, and I wonder if the problem got >> somehow fixed in one of those packages in the meantime. Could you >> please give it another try with 2.13.5-1 (sid) or 3.0.0-1 >> (experimental), and ideally both? This would establish an updated >> baseline for further investigation. > > Scheduled on amd64. Note however that I reported that the test didn't > always fail, so if it passes, it's not saying for sure that everything > is OK. > https://ci.debian.net/user/elbrus/jobs?package=apparmor Thank you. https://ci.debian.net/data/autopkgtest/unstable/amd64/a/apparmor/7743678/log.gz (sid) did not expose the problem. As you said, it does not prove anything. https://ci.debian.net/data/autopkgtest/unstable/amd64/a/apparmor/7743977/log.gz (experimental) failed because I asked you to trigger this too early: my 3.0.0-1 upload had not reached the archive. I've tried to re-trigger it myself but it seems that's not possible since the package is in the blocklist. Could you please re-trigger it? (package = apparmor, suite = unstable, pin = "src:apparmor, experimental") >>>> Is there a better way for me to investigate? >> >>> We have given DD's temporarily access to one of our workers before. If >>> you're interested we could do that again for this case. That way you >>> could even skip the upload to experimental, assuming it reproduces if >>> run from a local tree. And you can check what's going on in the test bed. >> >> This looks great. I'd like to do this once the updated baseline is >> established, if it still fails. I could book time for this on Nov >> 28-29. > > Can you can already point me at your public key? Easiest is with a > signed e-mail, but if it's otherwise easily traceable it's from you, I > can take it from elsewhere. Sure, will do right away in a private email. Cheers!
Bug#974896: RFP: elpa-company-quickhelp -- add documentation popups to company completion candidates
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-company-quickhelp Version : 2.3.0 + Git master Upstream Author : Dmitry Gutov * URL or Web page : https://github.com/company-mode/company-quickhelp * License : GPL-3 Description : add documentation popups to company completion candidates
Bug#974897: RFP: elpa-moody -- tabs and ribbons for the Emacs mode line
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-moody Version : 0.5.4 Upstream Author : Jonas Bernoulli * URL or Web page : https://github.com/tarsius/moody * License : GPL 3+ Description : tabs and ribbons for the Emacs mode line
Bug#589596: libexpect-simple-perl: We need tests (and examples)
Control: tag -1 + upstream Control: retitle -1 Upstream documentation could be clearer Hi, Gordon Haverland (2010-07-18): > If one looks at the man page for Expect::Simple, we see: [... copy of the synopsis] > The manpage code snippet does not define $cmd. I think that's OK as far as the synopsis is concerned. > Even looking at the send() command on the man page doesn't > really tell someone what $cmd is supposed to be. I see how it could be made clearer upstream. > An example that I guess > I will figure out myself, is what if the first send() isn't needed? Am > I supposed to send a zero length string, UNDEF, or not even call send()? The description reads: "Generally, one starts by creating an Expect::Simple object using new. This will start up the target program, and will wait until one of the specified prompts is output by the target. At that point the caller should send() commands to the program; the results are available via" I don't see how an Expect module can be useful without sending commands to the interactive prompt. > But a general comment as far as all CPAN modules goes, we really do need > the tests and any examples that are in the CPAN package. We do ship the tests in the source package. When upstream provides example scripts, we include them in the binary package. In this case there are none so we can't include them :) > And it would > be really nice if the web page describing libexpect-simple-perl (or > any libXXX-perl package) would actually say that this is the CPAN XXX > package. Indeed, this info is only available in the long description of the binary package, that for example is not visible on the tracker: https://tracker.debian.org/pkg/libexpect-simple-perl But if you click on the binary package link on that page, you land on https://packages.debian.org/unstable/libexpect-simple-perl, which includes the desired info. So, all in all, I think the only actionable aspect of this wishlist bug report are upstream stuff. Tagging accordingly.
Bug#973248: Deprecation warning in Ruby 2.7: $SAFE will become a normal global variable in Ruby 3.0
Control: tag -1 + patch Control: severity -1 important Hi, Miquel van Smoorenburg (2020-10-27): > I get this warning on a puppet run: > > /usr/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:126: warning: > $SAFE will become a normal global variable in Ruby 3.0 Confirmed here. I'm bumping the severity to "important" because with typical Puppet deployments, this bug will yield tons of noise in whatever monitoring system is used, which makes it pretty much unusable as-is. > So I tried another minimal approach. This fixes it for me, and it should > also fix those other deprecation warnings from #955532, so that patch > can be dropped if you want. The way #955532 was fixed (by backporting an upstream commit) seems cleaner to me so personally, I'd rather see the big-hammer approach proposed here used as little as possible. Below, I'll share the version of the patch that I'm now using. It only tackles the problem this bug is about, and I believe the code style is a bit more canonical Ruby (guard clause instead of "if" + unspecified else). Dear maintainers, I would like this bug to be fixed in Bullseye, to avoid having to maintain a local workaround on the Tails infra for the next 2-5 years. If it may help, I could negotiate a freeze exception with the release team, and if they agree, upload a NMU. What do you think? --- /a/puppet 2020-10-25 17:04:24.0 + +++ /b/puppet 2021-03-08 07:39:16.294675668 + @@ -1,5 +1,12 @@ #!/usr/bin/ruby + +def Warning.warn(w) + return if w =~ /warning: \$SAFE will become a normal global variable/ + + super w +end + begin require 'puppet/util/command_line' Puppet::Util::CommandLine.new.execute
Bug#948027: elpa-org: Does not ship org-notmuch anymore
Package: elpa-org Version: 9.3+dfsg-1 Severity: normal Hi! org-notmuch is not included in the package anymore. Apparently, with the 9.3 release, upstream renamed a bunch of contrib/lisp/org-*.el to contrib/lisp/ol-*.el. Could it be that the debian/elpa file needs to be updated accordingly? Thanks a lot for maintaining org-mode in Debian! :) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (2, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-org depends on: ii dh-elpa-helper 2.0.2 ii elpa-htmlize1.55-1 ii emacsen-common 3.0.4 Versions of packages elpa-org recommends: ii emacs 1:26.3+1-1 ii emacs-gtk [emacs] 1:26.3+1-1 Versions of packages elpa-org suggests: pn ditaa ii org-mode-doc 9.3-1 ii texinfo6.7.0.dfsg.2-5 ii texlive-fonts-recommended 2019.20191208-4 ii texlive-latex-extra2019.20191208-1 -- no debconf information Cheers, -- intrigeri
Bug#934119: [Pkg-privacy-maintainers] Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles
Hi, Roger Shimizu (2020-01-05): > I find this is due to below files were shipped by previous version of > torbrowser-launcher, but not as conffile. > /etc/apparmor.d/local/torbrowser.Tor.tor > /etc/apparmor.d/local/torbrowser.Browser.firefox Yes. > But now they're shipped with conffile, though in size zero. That's indeed the problem IMO. See below for my reasoning. > So new conffiles complain they don't match with existing ones. Right. > It can be fixed by removing the old files when they match the checksum > of old shipped ones. > The fix will be uploaded soon. I think this can help for files under /etc/apparmor.d/local/ that the package does not install at all anymore (be it via dh-apparmor or as conffiles). This would clean up stuff and that's good :) But I don't think it will help for local/torbrowser.Tor.tor and local/torbrowser.Browser.firefox, which this bug report was initially about. FYI, the very purpose of the files under /etc/apparmor.d/local/ is to be modified by the system administrator, that is, to diverge from what's shipped by packages under /etc/apparmor.d/. The content of these files will, by design, always be: local changes, done manually, and that packages and dpkg should not fiddle with. So, if /etc/apparmor.d/local/* are conffiles, and if the administrator is using this facility, upon upgrades their local changes will necessarily conflict with the (empty) version installed by the package, and dpkg will ask what to do. That would be pretty annoying, since the answer to dpkg's question in this case will always be "keep my local changes, because that's what this file is for after all :)". I hope this clarifies the drawback I see in handling these files as conffiles. Are there advantages in treating them as conffiles, that outweigh this drawback? Cheers, -- intrigeri
Bug#983114: libapparmor1: After upgrade is the system not bootable. Init is complaining about incorrect apparmor version.
Hi, Ďoďo (2021-04-11): > Hi, yes, I do agree the problem is in libc dependencies. I'm glad we're on the same page here. > Yes, I am using testing and I just did allow the apt to upgrade all > the recommended packages. > […] > Otherwise I do not understand your comment about "running testing on > stretch system". I'm not convinced at all that you're using testing. The original bug report read: > Debian Release: 9.8 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 'stable') > Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads) That's the Buster kernel. So to me it looks like you're using a mix of Buster and Bullseye. Please remove any APT source for anything older than Bullseye (which is now stable), fully upgrade to Bullseye, and report back if you can reproduce. Thanks in advance!
Bug#993565: libapparmor-perl: Consider removing libapparmor-perl
Package: libapparmor-perl Version: 3.0.3-1 Severity: normal I'm considering dropping the Perl extension in the 3.x packaging: it's not used by anything in Debian anymore and I seriously doubt there's any relevant, non-obsolete, 3rd-party code that uses it. Additionally, removing this package would make cross-building (#984582) significantly easier. Thoughts, opinions?
Bug#988697: apparmor: [....] Restarting apparmor (via systemctl): apparmor.serviceJob for apparmor.service failed because the control process exited with error code.
Hi, Роман Ращинский (2021-05-30): > Thank you! It seems there's been a misunderstanding. So again, please answer these questions: * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? … so we can understand what's the problem, and hopefully fix it :)
Bug#993568: dh-apparmor: Allow opting-out from creating local include
Package: dh-apparmor Version: 3.0.3-1 Severity: normal "include if exists" is well supported in AppArmor 3.x, so we could stop creating /etc/apparmor.d/local/$profile local include files. I don't think we can do that by default though: if we did, it would break loading newly installed profiles that still use #include.
Bug#983114: libapparmor1: After upgrade is the system not bootable. Init is complaining about incorrect apparmor version.
Hi, Ďoďo (2021-09-03): > Yesterday I noticed that some autoupgrade fully updated my TP. So I removed > testing, run dist-upgrade to current stable. (TP completely freeze > during the systemd upgrade) Then I rebooted and exactly the same problem. I > finished the upgrade (due to previous crash) and again. But the same > problem. > So I had downgrade libappramor1 again to be able to boot. :( In the original bug report I see this: - "Init: unable to detect" - "The last message before kernel crash was: /sbin/init can not find apparmor_2.13" So I'm wondering: 1. What init system are you using? Please share the output of this command: dpkg -S /sbin/init 2. What's the currently installed version of libc6? Please share the output of this command: apt policy libc6 3. What version of apparmor is installed when the bug happens? Please share the output of this command: apt policy apparmor libapparmor1
Bug#990554: tcpdump: leftover legacy configuration /etc/apparmor.d/local/usr.sbin.tcpdump
Hi, Romain Francoise (2021-07-03): > On Fri, Jul 2, 2021 at 1:57 AM Christoph Anton Mitterer > wrote: >> So is it tcpdump's responsibility to clean this up (manually) or should >> debhelper >> do it (somehow ^^) automatically, i.e. also migrate the existing file >> automatically, because people might have had config in >> /etc/apparmor.d/local/usr.sbin.tcpdump which should have gotten moved to >> /etc/apparmor.d/local/usr.bin.tcpdump >> >> So maybe this needs to be reassigned to dh-apparmor. > > Thank you for bringing this to my attention, I wasn't aware that the > dh_apparmor script snippets would create this file upon installation. > Technically the file isn't part of the package, so indeed it's not > clear whose responsibility it is to clean it up. > > Let's add a usertag to loop in the pkg-apparmor team... Thanks for adding us into the loop and sorry for the delay. That's a tough one. Indeed, dh-apparmor does not support profiles being renamed. I don't think it's worth adding such support because we'll soon be able to solve this class of problems in a nicer way: 1. dh-apparmor will allow _not_ creating this local include file (tracked as #993568) 2. once that's done, your profile can use "include if exists" instead of "#include" … and then the responsibility of creating/managing/renaming such include files will be the local system administrator's. Meanwhile, I'm afraid the only way to deal with such leftovers is via maintainer scripts, taking care of not deleting contents added by the user :/
Bug#990499: apparmor: Include local profile for sanitized_helper
Control: tag -1 + upstream Control: severity -1 wishlist Hi, Frank (2021-06-30): > The current setup for the profile sanitized_helper does not include a local > profile for adjustments. I would like to propose > > #include > > in /etc/apparmor.d/abstraction/ubuntu-helpers This makes sense to me. Now that we can target AppArmor 3.x, I would instead suggest: include if exists … so we don't have to create/manage local/ubuntu-helpers. Would you like to submit this as a merge request upstream? It would happen there: https://gitlab.com/apparmor/apparmor Cheers!
Bug#989193: [pkg-apparmor] Bug#989193: breaks apt-cacher-ng by blocking link operation
Control: tag -1 + upstream Control: forwarded -1 https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/51 Control: tag -1 + moreinfo Hi, Eduard Bloch (2021-05-28): > see attachment, your config which doesn't allow link calls, which > sporadically breaks operation of apt-cacher-ng in unexpected ways. Thanks! I've turned this patch into an upstream merge request. I see you've made this bug RC. I'd like to better understand the severity, so I can figure out what I should do for Bullseye. I'm wondering because I'm using this AppArmor policy on sid with apt-cacher-ng myself, and I can't find traces of such denials in my logs. Could you please help me understand what kind of apt-cacher-ng operations (or configuration) trigger these denials and are broken by the current AppArmor policy? Thanks in advance, cheers! -- intrigeri
Bug#989193: [pkg-apparmor] Bug#989193: Bug#989193: breaks apt-cacher-ng by blocking link operation
Control: severity -1 important intrigeri (2021-06-02): > I see you've made this bug RC. I'd like to better understand the > severity, so I can figure out what I should do for Bullseye. > I'm wondering because I'm using this AppArmor policy on sid with > apt-cacher-ng myself, and I can't find traces of such denials in > my logs. > > Could you please help me understand what kind of apt-cacher-ng > operations (or configuration) trigger these denials and are broken by > the current AppArmor policy? I'm downgrading severity until this is clarified: with the information _currently_ available to me, this bug does not make the package unfit for Bullseye, so triggering auto-removal seems a bit extreme. Happy to change my mind once I have more info :)
Bug#987298: gdm3: Fails to unlock GNOME keyring when multiple attempts were needed to unlock LUKS
Hi Simon, Simon McVittie (2021-04-30): > Sorry, I can't work out how to get a system where the bug you reported > would even be relevant. At this stage in the release process I am reluctant > to apply changes that I can't test - please could you describe how I can? Thanks for having considered my request so seriously. I feel like I've wasted your time and I'm sorry for this. I'm afraid this bug report I submitted turned into something vastly more complicated than I thought initially. I don't have the bandwidth to spend the time needed to move this forward for Bullseye. The bugfix will propagate to Debian on its own eventually so perhaps we can close this bug as "non actionable without extra work that I'm not in a position to do"? Cheers!
Bug#989193: [pkg-apparmor] Bug#989193: breaks apt-cacher-ng by blocking link operation
Control: severity -1 serious Hi, Eduard Bloch (2021-06-08): > I set it RC because it deliberately breaks other package's (legal) > operations, The whole purpose of AppArmor policy is to restrict operations to a pre-defined set. This package does nothing else than shipping opt-in extra AppArmor policy so its whole point is to restrict operations. Some of the forbidden operations may be, or become, legit: that's a bug (or a conscious trade-off) of AppArmor policy. If you combine these with your reasoning, then any bug in AppArmor policy that makes it block a legit operation, would be RC: I don't think this is a reasonable way to approach bug severity for AppArmor policy, because basically it would make bug severity a constant, and thus we can't use it anymore to prioritize our work, do release management, etc. Instead, the way we do it usually is to take into account the impact and risk of occurrence of such bugs. Which is why I asked for more information here :) > and installing such booby traps was not properly announced. I'm sorry I did not let you know that we were shipping AppArmor policy for apt-cacher-ng in apparmor-profiles-extra. I'm grateful that Laurent Bigonville did in July 2019 (#932177), though. I would appreciate if you used language less loaded than "booby traps" to express your thoughts here: as I understand it, a booby trap is meant to intentionally cause harm., which is _not_ my intention here. One thing to keep in mind here: apparmor-profiles-extra is opt-in. Users who have it installed intentionally decided to have more programs confined by AppArmor. > And because you take away the control over the package's behavior > from the maintainers and push them to "collaboration" […]. In a way > I don't like (shoot first, ask later). Point taken. I understand parts of your concerns here are more general than "breaks apt-cacher-ng by blocking link operation". Would some help from me, towards solving #932177 post-Bullseye, be sufficient to reach a mutually agreeable solution? I'm also open to removing the apt-cacher-ng profile from apparmor-profiles-extra, without blocking on #932177, if you prefer: I don't want to force AppArmor policy on you. This is negotiable. >> I can't find traces of such denials in my logs. > > Please. Just because you don't see issues does not mean that issues > don't exist. Of course. This is precisely why I asked you to help me understand in which cases these issues do exist, so I can assess severity. >> Could you please help me understand what kind of apt-cacher-ng >> operations (or configuration) trigger these denials and are broken by >> the current AppArmor policy? > > When the mentioned mechanism was put in place, regular operation started > breaking. This also affects the expiration jobs, therefore your cache > will keep growing when users use non-stable distros. OK, then indeed I think this bug is RC. Thanks! > Or what exactly did make you think that "rw" is okay and everything > else can be dumped? Where are we? "I see all cars on my road are > driving straight, means that we can remove all steering wheels"? > *facepalm* I hear you're unhappy and perhaps angry, but I think you're out of line here. This tone hurts and makes it more difficult and costly for me to keep striving for constructive communication and collaboration. Given the tone of this last paragraph, I'll assume these are rhetorical questions and won't spend time answering them. However, if you're genuinely interested in understanding why the profile has "rw" and not "allow everything", I'll happy to shed some light on how I usually develop AppArmor policy. Cheers!
Bug#932177: Please include apparmor profile directly in the package
Hi, Eduard Bloch (2021-05-24): > In case you have instructions on the proper process to get this fixed, > please let me know. Sure. The operations involved don't meet the freeze policy, so we'll have to wait until Bullseye is released. tl;dr: - Import and install an AppArmor profile. I would suggest the profile that's maintained upstream as a cross-distribution effort there: https://gitlab.com/apparmor/apparmor-profiles … but that's obviously your call. - Do the usual "take over a conffile from another package" dance: add Breaks+Replaces against the first version of apparmor-profiles-extra that won't ship the apt-cacher-ng profile anymore (ideally with "~" appended). We'll need to coordinate. - Add build-depends on dh-apparmor - Add a call to dh_apparmor in debian/rules. You'll find full, real-life examples in tcpdump 4.9.0-3, ntp 4.2.8p7+dfsg-1, and evince 3.20.0-2: they all took over AppArmor profiles that used to be shipped in apparmor-profiles-extra, which is great. > apparmor maintenance seems to be a case for the MIA team, their > contact address is still an Alioth mailing list. To me it looks like you're jumping to rather drastic conclusions a bit too hastily here. FYI, the mailing list you're referring to works just fine. A number of important and active teams in Debian have chosen to do the same. For example, it's hard to argue that the Debian Perl group is a case for the MIA team. It's true, however, that the Alioth mailing list continuation project is not meant to live forever. We'll cross that bridge once we get there. The number of uploads you'll see there should hopefully reassure you regarding MIA status of the AppArmor team: https://tracker.debian.org/pkg/apparmor https://tracker.debian.org/pkg/apparmor-profiles-extra (To be honest, this team currently has only 2 active people, each quite specialized, so like many other teams in Debian it's not awesomely sustainable. Oh well.) Cheers!
Bug#983108: Closing power-profiles-daemon ITP?
Hi, I see that power-profiles-daemon has been in experimental for a while? Is there any particular reason why we should not close this ITP? Thanks a lot for packaging this piece of software, can't wait to try it once GNOME 41 lands in sid with the corresponding GNOME Shell UI bits :)
Bug#992081: RFP: elpa-persistent-scratch -- preserve scratch buffers across Emacs sessions
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-persistent-scratch Version : 0.3.5 Upstream Author : Fanael Linithien * URL or Web page : https://github.com/Fanael/persistent-scratch * License : BSD 2-clause "Simplified" License Description : preserve the state of scratch buffers across Emacs sessions
Bug#992387: RM: libcloudflare-client-perl -- ROM; unusable, seemingly dead upstream, depends on deprecated libparse-keyword-perl
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986107 as Sean kindly requested. On top of the reasons mentioned there, this package has been completely unusable since 3 years: #983473. Thanks!
Bug#992388: RM: libnet-dns-cloudflare-ddns-perl -- RoQA; depends on libparse-keyword-perl, whose upstream says "DO NOT USE!"
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986107 as requested by Sean. Thanks!
Bug#992389: RM: libmoops-perl -- ROM; Please enter the reason for removal: depends on libparse-keyword-perl, whose upstream says "DO NOT USE!"
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986107 as requested by Sean. Thanks!
Bug#992390: RM: libkavorka-perl -- ROM; depends on libparse-keyword-perl, whose upstream says "DO NOT USE!"
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986107 as requested by Sean. Thanks!
Bug#992391: RM: asciio -- ROM; Depends on libgtk2-perl (deprecated upstream + GNOME team's goal of reducing gtk2 use in Debian)
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986109, as Sean kindly requested. The bug report about this package's dependency on libgtk2-perl is #912870. Unfortunately, the RFH I filed a year ago (#968843) was not sufficient. Thanks!
Bug#992392: RM: libdata-treedumper-renderer-gtk-perl -- ROM; Depends on libgtk2-perl (deprecated upstream + GNOME team's goal of reducing gtk2 use in Debian)
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986109, as Sean kindly requested. The bug report about this package's dependency on libgtk2-perl is #912874. The only reverse-dependency is asciio, whose removal I just requested. Thanks!
Bug#992393: RM: libcircle-fe-gtk-perl -- ROM; Depends on libgtk2-perl (deprecated upstream + GNOME team's goal of reducing gtk2 use in Debian)
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986109, as Sean kindly requested. The bug report about this package's dependency on libgtk2-perl is #932220 (compared to the other libgtk2-perl reverse dependencies that have 33 months old bug reports about it, this one was filed only 2 years ago, because the package was first uploaded to Debian 8 months after I announced that libgtk2-perl was going away). Thanks!
Bug#992394: RM: tinyca -- ROM; Depends on libgtk2-perl (deprecated upstream + GNOME team's goal of reducing gtk2 use in Debian)
Package: ftp.debian.org Severity: normal Hi, I'm splitting #986109, as Sean kindly requested. The bug report about this package's dependency on libgtk2-perl is #912889. I'll share some extra information here on top of what's already on #986109, because among the reverse dependencies of libgtk2-perl, this one is kind of a special case, for 2 reasons. First, "ROM" is clearly overstated here: tinyca is not maintained by a team I'm part of. However, I'm the maintainer for libgtk2-perl. Second, among the reverse dependencies of libgtk2-perl for which I just filed RM bug reports, this is the only one where some effort to port the package to current GTK happened. However, the product of this effort does not appear to have been published yet, and the information I see leads me to suspect this effort has been stalled since 11 months: https://bugs.debian.org/912889#36 So while there's some hope tinyca makes it back into Debian at some point, I don't think it warrants blocking the libgtk2-perl removal project which I started in November 2018. The package has not been installable on sid since October 2019 so removing it now won't change the situation for users. Thanks!
Bug#992469: debhelper: dh_installsystemd installs services in /usr/lib/systemd/system/
Hi, I faced the same Lintian warning when preparing the apparmor 3.0.3-1 upload: debhelper moves the systemd unit to /usr/lib/systemd/system/apparmor.service I was wondering whether Lintian was correct and whether this would actually cause trouble, especially on non-merged-/usr systems, so I installed the resulting packages in an up-to-date sid VM with non-merged-/usr. At first glance, everything seems to work just fine: - The service starts at boot as expected. - The output of "systemctl show -p UnitPath --value" and "systemd-analyze unit-paths" does include /usr/lib/systemd/system. So my impression at this point is that debhelper is doing the right thing, while Lintian is incorrect when assuming that /usr/lib/systemd/system is ignored. I'm wondering if I've missed anything. Theodore, you mentioned on -devel@ that this would "[break] on systems that don't have usrmerge installed". Could you please explain what it breaks? I'll refrain from uploading apparmor 3.0.3-1 until this is clarified. I've spotted one (somewhat cosmetic) problem though: the symlinks set up for Wants=/WantedBy= still point to /lib so they are now broken: /etc/systemd/system/sysinit.target.wants/apparmor.service -> /lib/systemd/system/apparmor.service This would of course not matter at all on a merged-/usr system. Even on a non-merged-/usr system I could not spot any problem this would cause, apart of some potential administrator confusion. Should I report this separately? Hoping it helps, cheers!
Bug#995909: python3-fava: Fails to start with jinja2 3.0.1
Package: python3-fava
Version: 1.18-1
Severity: important
Hi!
On current sid, starting fava fails here:
$ fava accounting.beancount
Traceback (most recent call last):
File "/bin/fava", line 33, in
sys.exit(load_entry_point('fava==1.18', 'console_scripts', 'fava')())
File "/bin/fava", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 850, in exec_module
File "", line 228, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/fava/cli.py", line 11, in
from fava.application import app
File "/usr/lib/python3/dist-packages/fava/application.py", line 67, in
app.jinja_options["extensions"].append("jinja2.ext.do")
KeyError: 'extensions'
Downgrading python3-jinja2 to 2.11.3-1, and python3-flask to 1.1.2-3,
fixes the problem.
I don't know if all main use cases of Fava are impacted, hence the
non-RC severity.
I understand this is upstream bug https://github.com/beancount/fava/issues/1266,
that's been fixed in the 1.19 release.
Thanks for maintaining Fava in Debian :)
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (2, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-fava depends on:
ii python3 3.9.2-3
ii python3-babel2.8.0+dfsg.1-7
ii python3-beancount2.3.3-1+b1
ii python3-cheroot 8.5.2+ds1-3
ii python3-click7.1.2-1
ii python3-flask2.0.1-2
ii python3-flask-babel 0.12.2-2
ii python3-jinja2 3.0.1-2
ii python3-markdown22.4.1-1
ii python3-ply 3.11-4
ii python3-simplejson 3.17.5-2
ii python3-werkzeug 2.0.1+dfsg1-2
python3-fava recommends no packages.
python3-fava suggests no packages.
-- no debconf information
Bug#986109: closed by Debian FTP Masters (Bug#986109: Removed package(s) from unstable)
Thanks!
Bug#990499: apparmor: Include local profile for sanitized_helper
Hi, Frank (2021-09-03): > https://gitlab.com/apparmor/apparmor/-/merge_requests/796 Great! > It might be as well better to add a patch to current Debian oldstable / > stable? I don't think this change qualifies for a stable update: it's more of an improvement than a bug fix, and local administrators already have a way to workaround the problem if needed. Cheers!
Bug#988204: apparmor: AppArmor container behavior inappropriate under WSL
Control: tag -1 + moreinfo Hi, Alistair Young (2021-05-07): > Specifically, systemd-detect-virt detects WSL as a container, > technically accurately, but this then causes the apparmor.systemd > script to decline to start apparmor. I'm trying to understand what's, at the end of the day, the desirable behavior here, and why. I understand you would like apparmor.service to start in a WSL environment, i.e. you would like the AppArmor policy to be loaded. Correct so far? May I infer that a container run under WSL can actually load and enforce AppArmor policy? In that case, IMO it would make much more sense to have is_container_with_internal_policy return true (0) for WSL containers, rather than tweaking apparmor.systemd to treat them as non-containers. Or is there any other reason why you want apparmor.service to start under WSL? Cheers!
Bug#988697: apparmor: [....] Restarting apparmor (via systemctl): apparmor.serviceJob for apparmor.service failed because the control process exited with error code.
Control: tag -1 + moreinfo Hi, Please answer these questions: * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? … so we can understand what's the problem, and hopefully fix it :)
Bug#987298: gdm3: Fails to unlock GNOME keyring when multiple attempts were needed to unlock LUKS
Package: gdm3 Version: 3.38.2.1-1 Severity: important Hi, On LUKS-encrypted systems, by default the GNOME keyring is encrypted using the LUKS passphrase typed on boot. pam_gdm unlocks the keyring using that passphrase. So far, so good. On current sid, pam_gdm uses the _first_ passphrase that was typed on boot. So if I mistype my passphrase on the first attempt, then type it correctly, pam_gdm will use the first (wrong) passphrase, and fail to unlock my GNOME keyring. As a result, all kinds of functionality that depends on the data in my GNOME keyring are broken, e.g. Chromium saved passwords. When this happens, I'm offered to unlock my keyring. It took me some research to figure out I had to type my LUKS passphrase, as opposed for example to my login password. I expect most Debian users would not discover this solution by themselves. It took me a while to understand what was going on, and why my GNOME keyring was seemingly randomly unavailable. I expect less technical users will just give up, assume GNOME keyring is totally buggy, and stop using it. Given how broad the impact is on unrelated software, one might argue this bug could qualify as RC. The upstream fix is self-contained and seems very simple. May we consider including it in Bullseye? I suppose it depends in part on how common we expect LUKS-encrypted systems to be among Debian + GNOME users. - Upstream bug report: https://gitlab.gnome.org/GNOME/gdm/-/issues/657 - Upstream fix: https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/136 - Longer story: https://github.com/systemd/systemd/issues/17565 Thanks for maintaining GNOME in Debian, Cheers!
Bug#986106: libparse-keyword-perl: Upstream says "DO NOT USE!", no significant usage in Debian
Package: libparse-keyword-perl Version: 0.09-1 Severity: serious As pointed out by Jonas Smedegaard a month ago¹, this module is deprecated upstream: the upstream homepage² explicitly states "DO NOT USE!". Jonas analysis lead him to conclude that we can, and should, remove this package and its (few) reverse (build-)dependencies from Debian. I agreed and AFAICT nobody challenged this reasoning. Let's start by ensuring this package is not shipped in Bullseye, thanks to this RC bug. I'll file removal requests for ftpmaster. [1] https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2021-February/144274.html [2] https://metacpan.org/pod/Parse::Keyword
Bug#986107: RM: libparse-keyword-perl -- ROM; Upstream says "DO NOT USE!", no significant usage in Debian
Package: ftp.debian.org Severity: normal Hi, As pointed out by Jonas Smedegaard a month ago¹, this module is deprecated upstream: the upstream homepage² explicitly states "DO NOT USE!". Jonas analysis lead him to conclude that we can, and should, remove this package and its (few) reverse (build-)dependencies from Debian. I agreed and AFAICT nobody challenged this reasoning. The reverse-dependencies are: libkavorka-perl libmoops-perl libcloudflare-client-perl libnet-dns-cloudflare-ddns-perl Please let me know if you'd like me to file removal requests for these 4 packages as well. [1] https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2021-February/144274.html [2] https://metacpan.org/pod/Parse::Keyword
Bug#986109: RM: libgtk2-perl -- ROM; Deprecated upstream + GNOME team's goal of reducing gtk2 use in Debian
Package: ftp.debian.org Severity: normal Hi, I'm hereby requesting removal of libgtk2-perl, as one of its maintainers, and of its remaining 4 reverse-dependencies, as the last step of a plan that was communicated to the relevant maintainers years ago. The reverse-dependencies covered by this request are: asciio, libcircle-fe-gtk-perl, libdata-treedumper-renderer-gtk-perl, and tinyca. In November 2018: - The Debian GNOME team announced¹ their larger effort to reduce gtk2 use as much as possible in Debian, including "For Bullseye, we are serious about our intention to remove […] libgtk2-perl". - I proposed² a plan to remove libgtk2-perl from Debian and filed bug reports against all reverse-dependencies. In July 2019 these bug reports were made RC. In October 2019, libgtk2-perl was removed from testing. In January 2021, Dominic Hargreaves and I discussed this topic³. We agreed to give the maintainers of the reverse-dependencies a last chance to get their package in Bullseye before migration of new source packages to testing is disabled (2021-02-12), and then to remove libgtk2-perl and its remaining reverse-dependencies from sid at any time after 2021-02-12. We've now reached this point and I think it's time to proceed with the removal: the maintainers of the remaining reverse-dependencies have now had between 20 and 28 months to port their package to GTK3, or ask upstream to. Here's a summary of the status of these reverse-dependencies: - asciio (#912870): bug not marked as forwarded upstream; I filed a RFH in August 2020, nobody volunteered; last upstream release in 2015; popcon votes = 12 - libcircle-fe-gtk-perl (#932220): bug not marked as forwarded upstream; uploaded after the removal plan was announced, never reached testing; last upstream release in 2017; popcon votes = 0 - libdata-treedumper-renderer-gtk-perl (#912874): bug not marked as forwarded upstream; no upstream activity since at least 2016; popcon votes = 12 (which matches asciio, it's only reverse-dependency) - tinyca (#912889): bug not marked as forwarded upstream; upstream homepage lost since Alioth was shut down; porting work started in September 2020, no news since then; popcon votes = 59 Please let me know if you'd like me to take extra steps in order to get these packages removed, since I don't maintain them myself. [1] https://lists.debian.org/debian-devel/2018/11/msg00570.html [2] https://bugs.debian.org/912860 [3] https://bugs.debian.org/942135#91 Cheers!
Bug#912860: Requested removal of libgtk2-perl from unstable
Hi, FYI, after a 28 months long process, I've just requested the removal from unstable of libgtk2-perl and its reverse-dependencies, which includes this package: #986109. If you, or someone else, still cares about this package, I hope they'll succeed in porting it to a current GUI toolkit, such as GTK 3, and this package can come back to Debian some day :) Cheers!
Bug#983114: libapparmor1: After upgrade is the system not bootable. Init is complaining about incorrect apparmor version.
Control: tag -1 + moreinfo Hi, Ivanecky Jozef (2021-02-19): > Package: libapparmor1 > Version: 2.13.6-9 > Debian Release: 9.8 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 'stable') > Versions of packages libapparmor1 depends on: > ii libc6 2.31-9 It looks like you've upgraded key packages (libapparmor1, libc6) to the version from testing/sid on a Stretch system. Is this correct? This kind of setup is unsupported and I'm afraid there's little chance it'll work. I suspect the problem here is about the libc6 upgrade, rather than about AppArmor, by the way.
Bug#984582: [pkg-apparmor] Bug#984582: apparmor FTCBFS: many different reasons
Hi Helmut, First: wow, great investigative work! Helmut Grohne (2021-03-05): > So I have a longer patch fixing 1-6 attached. Please consider applying > it. I guess this is post-bullseye material though. Of course you can > give some feedback pre-bullseye to move this forward. I would be happy to review a patch series. Indeed, this can totally happen without being blocked by the freeze. Here's what I'd like to review: - atomic patches (ideally as a MR on Salsa, but if that's too inconvenient for you, I can live with the email workflow; it's just less motivating, so you should expect longer delays): all changes bundled in one single diff is too painful for me to review and to selectively apply - based on the current 3.x (debian/experimental) codebase: both the upstream code and the packaging have changed quite a bit since 2.13.x and I'd rather not have to forward-port these changes Fair enough? Additionally, I'm considering dropping the Perl extension in the 3.x packaging: it's not used by anything in Debian anymore and I seriously doubt there's any relevant, non-obsolete, 3rd-party code that uses it. I understand this move would simplify your work a fair bit, and for me it's another reason in favor of dropping libapparmor-perl. So you could ignore the Perl bits for now :) Cheers!
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
Control: tag - moreinfo Control: tag + wontfix Hi, Christian Ehrhardt (2021-02-08): > I'm already part of the crowd waiting for "Include if exists" to be > widely available. > And yes, that would solve my problem as well. > > But IMHO a huge problem with "Include if exists" is, that on older > apparmor it totally breaks the rule parsing. > That makes it hard to fully jump onto the new feature yet: > - upstreams don't know how far back their SW will be built, this would > need to become at least a build time version/feature check against > apparmor > - distro-packaging often enough is used for backports, where again > we'd need code to handle old and new feature sets I hear you and I understand this set of conflicting constraints is difficult to disentangle :/ > But thinking more about it I think I still agree that we can close this bug. > That is because in the (hopefully few) places we need this we can > handle it (a bit ugly) in the maintscripts. > If we'd fully support it in dh-apparmor it might encourage people "too > much" to use that instead of the hopefully better future of > "include-if-exists". This makes sense to me. I'm marking this bug as wontfix for now, so that other folks who wonder why dh-apparmor lacks this feature can find the answer. Thank you all for the constructive discussion, cheers!
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Hi Paul, Paul Gevers (2021-02-18): > Hi intrigeri, > > On 18-02-2021 10:34, intrigeri wrote: >>> # Dummy test so that changes to linux-image-amd64 trigger our other >>> autopkgtests >>> # on ci.debian.net > > By the way, we have the "hint-testsuite-triggers" for this. > >> Actually, apparmor-profiles-extra has the exact same test, and AFAICT >> it seems to run pretty reliably there, so I now have doubts about the >> hypothesis I quoted above. >> >> Still, perhaps it's worth trying to add isolation-machine to that >> test, remove src:apparmor from the blocklist, and see what happens? > > If you add that restriction (instead of the current ones), the test > isn't run anywhere (and can't cause any issues). Thanks! In 3.0.1-6 (experimental) I've replaced the current restrictions with hint-testsuite-triggers, i.e.: Test-Command: /bin/true Depends: linux-image-amd64 [amd64] | linux-image-generic [ amd64 ] -Restrictions: superficial, skip-not-installable +Restrictions: hint-testsuite-triggers I've verified that the resulting .dsc has the same Testsuite-Triggers field. I would like to see the same 1-line change in Bullseye, in the hope that it's enough to allow you folks to remove src:apparmor from the blocklist. Would you like to pre-approve this here, or do you prefer that I request pre-approval via the regular release team process? Cheers, -- intrigeri
Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure
Paul Gevers (2021-04-02): > On 02-04-2021 14:00, intrigeri wrote: >> I would like to see the same 1-line change in Bullseye, in the hope >> that it's enough to allow you folks to remove src:apparmor from >> the blocklist. > > Shall we test first if it helps? Sure :) I understand I can't do this myself.
Bug#986309: surf: Please update embedded copy of the AppArmor gstreamer abstraction
Package: surf Severity: serious Version: 2.0+git20201107-1 Hi Reiner! This autopkgtest: Test-Command: cmp /etc/apparmor.d/abstractions/surf-gstreamer /etc/apparmor.d/abstractions/gstreamer … fails since I've uploaded apparmor-profiles-extra 1.32, which modifies /etc/apparmor.d/abstractions/gstreamer. This blocks the migration of apparmor-profiles-extra to testing. Could you please update your copy of that file? (Longer term, this makes me less convinced that the strategy chosen in #901416 and #912026 a few years back is ideal. If you'd like to re-consider this, e.g. to replace the copied abstraction with a dependency on apparmor-profiles-extra at some point, let me know if there's anything you need from me.) Cheers, -- intrigeri
Bug#934117: torbrowser-launcher: Does not remove obsolete /etc/apparmor.d/torbrowser.Browser.plugin-container conffile on upgrade
Package: torbrowser-launcher Version: 0.3.2-1 Severity: normal Hi, Upgrading the package, on my sid system, to 0.3.2-1, leaves the obsolete /etc/apparmor.d/torbrowser.Browser.plugin-container around. I believe debian/torbrowser-launcher.maintscript should take care of removing it. Cheers! -- intrigeri
Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles
Package: torbrowser-launcher Version: 0.3.2-1 Severity: normal With this version, /etc/apparmor.d/local/torbrowser.Browser.firefox and /etc/apparmor.d/local/torbrowser.Tor.tor are managed as conffiles again, while they should not: they're supposed to be created/deleted as needed by bits of maintainer scripts generated by dh_apparmor. A problematic consequence is that if I have local tweaks in those files (which is their actual intended purpose), I'm asked on upgrade to resolve the conflict between my configuration and the empty one shipped by the package. I believe we've had the same bug in the past, that got fixed in d0deb2f923edbaf3c2801c46d74b7925c5605593. I'm not sure what exact rm_conffile call would be suitable here (depends on which upgrade paths we shall support). Cheers, -- intrigeri
Bug#934389: memlockd service is not enabled under systemd
Package: memlockd Version: 1.2+b1 Severity: important Hi, after installing memlockd on a mostly clean sid VM, the service starts correctly, but it's not started on subsequent boots: # systemctl status memlockd.service ● memlockd.service - memlockd Loaded: loaded (/lib/systemd/system/memlockd.service; disabled; vendor preset: enabled) Active: inactive (dead) I see nothing in memlockd.postinst about systemd and no symlink in /etc/systemd/system/*.wants/. It looks like the fix for #714957 only partially fixed the problem. (FWIW, I would dive deeper and probably propose a patch if debian/rules was more similar to what I'm familiar with, i.e. if it used the dh(1) command sequencer, but in its current state it's too far out of my comfort zone.) Cheers, -- intrigeri
Bug#935058: torbrowser-launcher: Fails to start because apparmor prevents acces to mutter/xwayland xauth file
Control: reassign -1 apparmor Control: found -1 2.13.3-4 Control: affects -1 torbrowser-launcher Control: tag -1 + upstream Hi Frederik, Frederik Himpe: > torbrowser-launcher fails to start with this apparmor message in kernel log: > [ 135.043787] audit: type=1400 audit(1566153604.771:58): apparmor="DENIED" > operation="open" profile="torbrowser_firefox" name="/run/user/1000/.mutter- > Xwaylandauth.B4GI6Z" pid=4793 comm="firefox.real" requested_mask="r" > denied_mask="r" fsuid=1000 ouid=1000 > This happens when starting torbrowser-launcher in a GNOME Wayland session with > Mutter 3.33.90-2 from Experimental. Oh, interesting, good catch! I did not know that this new version of GNOME changed the path to this Xwayland thing. I'm very glad you spotted this, thanks! :) I believe this needs to be fixed in /etc/apparmor.d/abstractions/wayland, thus reassigning. I'll prepare a merge request upstream and will fix this in Debian ASAP. Can you please add the following line to /etc/apparmor.d/abstractions/wayland owner /run/user/*/.mutter-Xwaylandauth.* r, … then reload the affected profile with: sudo apparmor_parser -r /etc/apparmor.d/torbrowser.Browser.firefox … and retry? Thanks in advance! I assume this will break any app running under Xwayland and confined by AppArmor, so this bug report will become RC once GNOME 3.34 is released and uploaded to sid. Cheers, -- intrigeri
Bug#767103: irssi-plugin-otr needs rebuild on new uploads of irssi
Control: fixed -1 1.2.0-1 Hi, I think this bug is moot given the irssi-plugin-otr binary package is now built from src:irssi. Cheers, -- intrigeri
Bug#911356: ikiwiki: "po" plugin can insert raw ".po" file contents with [[!inline ... ]] directives
Hi Simon, intrigeri: > I will now deploy a modified version of ikiwiki, that includes your > patch, on our production website, which will give it exposure to more > realistic usage. I'll report back in 7-10 days, which hopefully should > leave sufficient time for getting the fix in Buster; Nine days later, I've not spotted any issue with your patch there. It's worth noting that in the meantime we've released a new Tails, that pretty often triggers this very bug. So please apply your patch to ikiwiki upstream :) It would be sweet if this could make it into Buster but if that's too late, no worries (it took me some time to reply in the first place). Cheers, -- intrigeri
