[00:06] That CVE (https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-79w7-vh3h-8g4j) looks more Windows based. === chris14_ is now known as chris14 [12:43] mdeslaur or sarnold maybe: please could you see if you have an opinion on bug 2065915 or could otherwise help out? It seems like a couple of community contributors are trying to fix up quite a bit of a mess in relation to apparmor, possibly related to userns. I'm also not sure what to make of it from an SRU review perspective and would appreciate your opinion. [12:43] -ubottu:#ubuntu-security- Bug 2065915 in tellico (Ubuntu Noble) "[SRU] Fix hard coded path in apparmor profiles." [Undecided, New] https://launchpad.net/bugs/2065915 [12:44] Or jjohansen maybe? ^ [12:47] hrm https://launchpadlibrarian.net/738546122/plasma-welcome_5.27.11-0ubuntu3_5.27.11-0ubuntu4.diff.gz [12:48] that looks weird, I don't now what that is solving [12:48] related bug: https://bugs.launchpad.net/ubuntu/+source/akregator/+bug/2064492 [12:48] -ubottu:#ubuntu-security- Launchpad bug 2064492 in tellico (Ubuntu Noble) "failed to execvp: /usr/lib/aarch64-linux-gnu/qt5/libexec/QtWebEngineProcess" [High, Fix Committed] [12:49] I'll let sarnold and jjohansen comment [12:49] AIUI, it's trying to solve that bug you linked. See comments in the 915 bug. [12:49] Thanks === Jozo_ is now known as Jozo === jozo_ is now known as Jozo [13:22] rbasak: it seems that the packages from the SRU use userns and to make it work they created a profile based on what was done for plasmashell https://git.launchpad.net/apparmor/tree/profiles/apparmor.d/plasmashell which doesn't really make sense for those applications. it seems that what they actually wanted in the first place was an unconfined profile similar to epiphany https://git.launchpad.net/apparmor/tree/profiles [13:22] /apparmor.d/epiphany which is what the SRU is proposing... now we have to decide what's worse: fix only the @{multiarch} aspect and leave an apparmor policy that is overly broad and doesn't make sense for the package but confined nonetheless or use the flags=(unconfined) which I believe should have been the initial policy and makes it consistent with what we're doing in the apparmor package but now makes the [13:22] application unconfined [13:24] georgiag: ah that's a helpful analysis thanks. [13:27] If the multiarch paths are fixed, then that would be a minimal safe change that we can have confidence in. The risk is that there are other code paths not being exercised that will continue to fail I suppose, but it might be reasonable to wait for such a bug report before deciding to go fully unconfined. [13:27] OTOH if we have a few examples of where the confinement is a problem in other cases, then that would provide some justification towards dropping the confinement altogether across these packages. [13:28] Perhaps that will help make a decision? If the security team reaches a (documented) conclusion of the preferred path with sgmoore in the bug, then I see no reason why the SRU team would want to do something different. [13:30] rbasak: dropping confinement is going to be really problematic going forward. unconfined profiles are just a temporary place holder as well. Those will get transitioned to real profiles [13:31] multiarch is looser than we like but it will get tightened. Fixing conditionals so they can be applied to variables is on the todo list [13:32] then multiarch will be able to be specific to distro and even runtime platform [13:36] for the SRU: [13:36] - new profiles can be flags=(unconfined) [13:36] - new profiles should have a non-path based name, and the attachment can use the multiarch var [13:36] - existing profiles should just be adjusted to use multiarch