[00:14] someone reported the epiphany crash https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/2046844 [00:14] -ubottu:#lubuntu-devel- Launchpad bug 2046844 in epiphany-browser (Ubuntu) "Epiphany browser does not launch on Ubuntu 24.04: core dumped" [Undecided, New] [00:14] but time for sleep here [00:14] ok so I'm getting a SIGILL even with host CPU passthrough, so it's not a problem with CPU features. [00:46] did some Wayland experiments with labwc, which more-or-less failed miserably. I think Wayfire is likely going to be better. [00:46] perhaps I'm just doing it wrong though, or maybe stefonarch's scripts are out of date [01:30] nothing like discovering that your keyboard is stuck in German when trying to do a Wayland experiment XD [01:42] Miriway? [01:43] [matrix] Tested, the empty bar appears in the middle of the screen. [01:43] [matrix] :( [01:44] [matrix] It seems that lxqt-panel is not ready yet [01:45] lxqt-panel requires window rules to work. [01:45] but it can work [01:46] I made some progress but for some reason the xdg-Lubuntu-Wayland folder isn't getting picked up [01:47] [telegram] According to stefonarch it doesn't work in wayland, that's why he uses another bar [01:47] oh really? On his repo he commends about lxqt-panel, "Window rules are needed until Qt 6.5 is fully implemented." And I found https://labwc.github.io/integration.html#:~:text=In%20order%20to%20integrate%20componenents,always%20support%20per%2Doutput%20configuration. [01:47] (excuse the Chrome-mangled link) [01:48] [telegram] Ouch [01:48] [telegram] I see [01:51] [matrix] For miriway and lxqt there is a script, but it doesn't work for me. [01:52] hey, making progress! [01:52] I finally got theming right [01:52] https://i.imgur.com/hRqjsQz.png [01:52] bar is horribly mangled but that's on the to-do list :P [01:54] [matrix] https://github.com/Miriway/Miriway/blob/main/example-configs%2Fmiriway-config-LXQT.bash [01:54] [matrix] Wouuuuu!! [01:54] The main issue is that these scripts are horribly horribly horribly *focused* - they're made as if they're a proof-of-concept to get one dev's machine working and that's it. [01:54] I guess they kind of are... [01:55] but they need a lot of work to become Lubuntu-ready, which is what I'm trying to do now. I may just end up with another dev homebrew hacky mess, but we can hope not... [01:57] One issue here is that it doesn't look like this stuff has very good support for XDG at all yet, either that or else I'm doing something wrong [01:59] hmm, I may just be doing it wrong [02:02] arraybolt3: Remember, XDG stuff comes from SDDM, which is a layer up :) [02:02] hmm [02:02] really. [02:02] The .desktop file must exactly match Lubuntu-Wayland.desktop in this case. [02:02] Well it does... [02:02] yeah lemme grab the docs [02:02] ...and it's not getting added to $XDG_CONFIG_DIRS [02:03] anyway most of this is relatively low-priority compared to the fact that lxqt-session just flat out fails silently on almost everything. [02:03] I have to launch every single component manually in a startup script which is waaaay less than ideal. [02:03] Here's a step-by-step on what pulls from what: [02:03] SDDM pulls the session name from /usr/share/xsessions when logging in. In our case, it's Lubuntu.desktop. Therefore, the DESKTOP_SESSION environment variable is set to Lubuntu, from this filename. Please note that we had to patch SDDM to do this properly; it used to make DESKTOP_SESSION an absolute path, which, when we continue in these steps, breaks things. TODO: send this upstream. [02:03] xorg sets the XDG_CONFIG_DIRS environment variable to /etc/xdg/xdg-DESKTOP_SESSION and /etc/xdg and XDG_DATA_DIRS to /usr/share/DESKTOP-SESSION and usr/share at minimum. NOTE: this is an Ubuntu-specific patch in xorg. [02:03] [startlxqt](https://github.com/lxqt/lxqt-session/blob/master/startlxqt.in) then grabs the values of XDG_CONFIG_DIRS and XDG_DATA_DIRS to use in the call to startlxqt, which then does a one-time copy of the settings from the first entry in both. [02:04] For a while before we could figure it out, the Lubuntu Next 18.04 image had a black screen on the live CD and on bootup of a new Lubuntu Next system. The LXQt system had been logged in, but nothing was visible. This is why we had to patch SDDM, because the value of XDG_CONFIG_DIRS didn't have our valid XDG path; it was an absolute path put onto /etc/xdg/xdg-. So therefore, if the situation ever [02:04] comes up again, it means that XDG_CONFIG_DIRS can't find valid settings. This also caused Simon to confront upstream; they had moved the default settings to /usr/share from /etc/xdg because they believed that it would apparently make it easier for distributors. Not only did they not consider that /usr/share is not in the XDG spec, they did no verification in LXQt itself to ensure that /usr/share [02:04] at minimum is always there. When Simon submitted a patch, it was rejected on the grounds that it was too distro-specific, which was ironic because they didn't follow the XDG spec. Alf has since reconsidered and asked Simon to resubmit the patch. [02:04] [matrix] Ammm [02:04] [matrix] [02:04] [matrix] [02:04] If you rename /usr/share/xsessions/Lubuntu.desktop to something else, please do change /etc/xdg/xdg-Lubuntu/ to the same name. Otherwise none of our settings will be applied. [02:04] [matrix] Miriway is an effort for bringing Wayland to desktops not currently having native Wayland support [02:04] ah, xorg sets XDG_CONFIG_DIRS. [02:04] Bingo. [02:04] labwc doesn't :D [02:04] [matrix] :O [02:05] so therefore startlxqtlabwc will have to [02:05] which is very easy [02:05] I wrote all of those notes *five* *years* ago. I knew we'd need them someday. [02:05] nicely done [02:05] And hey, if you wanna add anything to these notes, feel free :D [02:05] thanks [02:06] well at least it unravels the current mystery. [02:06] Right now if I can just get lxqt-session to work, I'll be way closer to success. [02:06] I remember spending like a full-time week banging my head against the wall on this, so I vowed that nobody shall have to deal with this pain again. :P [02:07] (This was the one time where I had to touch X11 itself, SDDM, casper, ubuntu-cdimage, debian-cd, etc. all at once) [02:07] grief [02:07] sounds like "fun" [02:07] When I say it gets worse, I mean it. :P [02:08] (As in, things that may go wrong.) [02:10] Anyway, let me know how far you get. I also appreciate the energy (and the efforts, this is cool!) but we likely have bigger fish to fry this time of cycle. [02:11] I think the idea would be that we focus hard on this and bugfixing post-FF. [02:11] That being said, please, continue your work and document your findings, so we at least have a starting point. Just don't sink days into it please :) [02:12] Just trying to look at things from a bigger point of view, not to de-motivate by the way: that's my job as Release Manager, I think? :) [02:15] I'm mainly working on this because it's something to do after some stress from earlier today (in multiple areas). [02:15] Not a problem at all, thank you for what you do arraybolt3 :) [02:16] arraybolt3: That's partly why I asked where the critical bug was, because I know we've both made a day of it... XD [02:18] right? [02:36] arraybolt3: I'm hitting the hay, I'll loop back bright and early for ya. [02:36] Did LoB ever sponsor qtilities btw? [02:36] * tsimonq2 checks NEW heh [02:36] I think he did. [02:38] Ah, yep I see it :) [02:38] Perfect! [02:38] Anyway, o/ :) [15:08] OK, vote on it. Do I dare attempt to build qtwebengine? >:-) [15:13] [telegram] Like a NCR? [15:14] Not quite, I'm going to try dropping to FORTIFY_SOURCE=2. [15:14] I suspect that's what's going wrong... maybe... [15:15] [telegram] Oh fun. It is only time right :P [15:16] heh [15:16] maybe epiphany-browser won't take so long to build, idk [15:16] webkit is actually way faster. Not fast, but fast*er* at least. [15:17] [telegram] Valid point. [15:19] Since they're both hitting the same SIGTRAP, one assumes it will work in both places, though granted Epiphany seems to *almost* not die if you try to `continue` it past the breakpoint, whereas Falkon dies horribly with an illegal instruction signal. [15:19] so they might not be closely related enough [15:20] at any rate both are a problem so I'll try and do Epiphany first. [15:20] [telegram] Your theory is sound to me. [15:21] [telegram] "If _FORTIFY_SOURCE is set to 1, with compiler optimization level 1 (gcc -O1) and above, checks that shouldn't change the behavior of conforming programs are performed." [15:22] [telegram] "With _FORTIFY_SOURCE set to 2, some more checking is added, but some conforming programs might fail." [15:24] This could also be the fault of the new GCC come to think of it. [15:24] [telegram] I was diverting down that rabbit hole too. [15:24] The only way I can even think that SIGILL could be hit on modern hardware is if a jump was made into the middle of an instruction, thereby shifting things all around. [15:25] At least with Epiphany there appears to be a real breakpoint set (which is getting built for... some reason?), but with Falkon, I wonder if the SIGTRAP is because the processor hit a misaligned instruction that just so happened to be a software breakpoint. [15:25] * arraybolt3 does not understand assembly in general all that well and doesn't understand x86_64 instructions at all, so I might be misguided here [15:26] I watched Ben Eater's "Hello World on a 6502" series and learned some 6502 assembly from that, that's about it :P [15:27] [telegram] I haven't touched assembly since college. That was... a while ago. [15:27] https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags looks like Fedora's been using FORTIFY_SOURCE=3 all year without ill effects... [15:28] I suppose I can check their spec file for epiphany and see what they're doing [15:28] [telegram] Yeah, I think they are O3 for everything too [15:28] [telegram] by default [15:28] yuck [15:28] [telegram] I know Suse moved in that direction as well [15:30] Fedora's Epiphany package seems surprisingly straightforward... [15:30] ...so that leads me to suspect the compiler more than the FORTIFY_SOURCE flag [15:31] though both changes were made at once so technically anything is possible [15:33] well anyway, I'm going to start by dropping back to FORTIFY_SOURCE=2 since that's easier. If that fails, then I get to rebuild GCC [15:33] which could be fun if the current compiler is b0rked [15:35] [telegram] Um yeah. [15:35] interestingly Epiphany in Ubuntu has -O1 set [15:35] in DEB_LDFLAGS_MAINT_APPEND [15:48] alright, build started [15:52] umm, Epiphany must depend on a webkit package because that was *way* too fast [15:53] not sure why I didn't think of that [16:06] Build is going. Of course it's only using like one core, but meh, good enough. [16:06] maybe two cores, I hope so [17:56] looks like my FORTIFY_SOURCE hack is working, though hilariously on at least one file, it gets set to 2, then redefined to 3, then back to 2 again :P [18:00] -O1 [18:00] (Not a typo or a fat finger.) [18:03] arraybolt3: Can we reproduce this on Debian Sid? [18:03] If we can, it's most certainly something DeltaOne would like to know about. [18:03] the weird failures? [18:03] yeah [18:03] Dunno yet, could you try it? [18:03] My machine is fully engaged in building WebKit. [18:04] * tsimonq2 grabs some kind of Debian ISO... [18:04] tsimonq2: meh, don't bother, use this: [18:04] https://github.com/ArrayBolt3/debflex [18:04] tsimonq2: ^ generates Debian VMs for you with a single command [18:05] they're very minimal, you need to specify the list of packages you want in fairly gory detail (like you can accidentally leave out sudo if you're not careful), but it works well and I'm using it all the time. [18:05] niceeeee [18:05] (debflex is the eventual name of the project, right now the actual script is gen-debvm, but I hope to develop it into something more fully fledged.) [18:05] oh btw it can generate Ubuntu VMs too :D [18:06] just be careful with that if you use qemu-nbd, it assumes it can hork /dev/nbd0 for itself [18:06] [telegram] *sips on coffee as he watches his computer spin up 20 LXD-powered minimal system containers for build envs* [18:07] @teward001: LXD is a bloated overrated mess, don't use it [18:07] * arraybolt3 ducks [18:07] [telegram] 👀 [18:08] * genii twitches [18:11] arraybolt3: I don't wanna hear anything about "bloated" coming from the guy who literally runs bare qcow2 files :D [18:13] lol, if it's any consolation I mostly use bare qcow2 files because of frustration with libvirt and VirtualBox. [18:14] (every so often libvirt or a connection thereof randomly dies on me and needs a full host reboot to fix, VirtualCrud is a glitchy, crashy mess even on Linux, and while LXD is nice, it's just so horribly complicated I can't hardly make heads or tails of the command lines I'm reading unless they're like the absolute basics.) [18:15] (QEMU is powerful and has much that I don't understand, but everything in it is relatively easy to piece together so I'm able to comfortably use and memorize the features I need often, and learn the ones I need seldom. And it seems to be more stable for me.) [18:28] arraybolt3: You do realize the difference between LXD and QEMU is that LXD shares the system kernel and QEMU doesn't right? [18:29] I'd argue that's WAY more lightweight heh [18:29] And the shed for the bike should be blue... [18:29] :P [18:29] that's a valid point, but still, it's MENTAL BLOAT because it makes me remember too much!!!!!!1111!!!11 [18:29] * tsimonq2 sends arraybolt3 some flash cards XD [18:32] in all seriousness I just know my toolkit and like it already. I'll use LXD when the time comes that I really need it and can learn how to use it properly. [18:33] * arraybolt3 still remembers agonizing over the QEMU for Windows documentation back when I was still on Win8 and thought QEMU was a good alternative to VBox on Windows... [18:41] omg I forgot how much customization we do in Lubuntu >_< [18:41] Ctrl + Alt + T doesn't even work out of the box.... [18:42] starts just fine here? [18:43] That being said, don't blindly take my word for it. If I can't reproduce it on a Noble VM, it's probably something deeper. [18:44] [telegram] I've been able to replicate it on different (L)Ubuntu machines. [18:46] sigh, your point about LXD taking less resources is wearing on me... [18:46] [telegram] Don't let it [18:46] [telegram] I use both [18:46] I'm going to have to recreate my whole build environment AGAIN just to get faster speeds XD [18:47] (Currently all of my sbuilds are done inside a VM) [18:47] (which runs headless and I SSH into) [18:47] [telegram] Don't chase waterfalls [18:47] haha [18:47] valid point [18:47] aaaaHA I got it [18:47] kay time to dig deep [18:47] [telegram] If you have something that makes you efficient carry on [18:47] tsimonq2: got it to crash? [18:48] * arraybolt3 is on file 6837 of 6863 that needs compiled for WebKit [18:48] [telegram] >.< Almost thhere [18:49] arraybolt3: yes [18:50] oh no that was just one component of WebKit that finished [18:50] sigh [18:50] * arraybolt3 needs to figure out why it's only using two of eight processors to do its job... eventually [18:52] arraybolt3: WebKit or WebEngine? [18:52] WenKit [18:52] Epiphany browser [18:52] ahhhhh okay [18:53] supposedly was going to take 30 minutes or so to build, now hours later... [18:53] but hey, better than a whole day [19:04] https://paste.ubuntu.com/p/h3SPJMFRpP/ [19:06] [matrix] Hmm, jump depends on uninitialized value... that sounds like it could cause something to jump into the middle of an instruction alright [19:07] [matrix] did we just have a Qt update that might be at fault here? I'm realizing I'm quick to blame compilers and whatnot because of the problem with Epiphany, but I wonder if both of them going buggy at the same time is a red herring. [19:09] ==5231== by 0x69799EE: QStandardPaths::writableLocation(QStandardPaths::StandardLocation) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10) [19:09] Makes me think it's a Qt bug. [19:09] We should eliminate PyQt5 as a variable in the process [19:10] [matrix] easy, test Falkon, it's pure Qt/C++ right? [19:12] Very similar errors: https://paste.ubuntu.com/p/HGQmkRpbBM/ [19:12] These two lines are exactly the same: [19:12] [5405:5405:1219/191120.152880:FATAL:credentials.cc(125)] Check failed: . : Permission denied (13) [19:12] ==5405== by 0x62E19D4: QWebEngineProfile::defaultProfile() (in /usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5.15.15) [19:12] (Meaning, between the two pastebins.) [19:22] [telegram] i should just give you the five minute tutorial for LXD containers lol. Its *really* not that complicated for basic use xD *sips coffee, realizes he ran out* (re @lubuntu_bot: (irc) (every so often libvirt or a connection thereof randomly dies on me and needs a full host reboot to fix, VirtualCrud is a glitchy, crashy mess even on Linux, and while LXD is nice, it's just so horribly complicated I can't hardly make [19:22] [telegram] genii go fetch coffee. [19:23] * genii snarls ferally and lopes off to the coffeepot [19:24] XD [19:26] interestingly GNOME Web seems to be *working* once inside Valgrind over here... [19:27] like I got a window with a new tab page and am now loading Google.com in it [19:27] so that's beyond weird [19:27] yep, Google seems to be loading right [19:28] This incredibly basic script also fails: https://paste.ubuntu.com/p/C7VTnBqkdY/ [19:28] nice [19:35] Wow. So if you ever need reminded how painfully slow GTK is, keep in mind that *all of KDE* can be run under Valgrind for testing, yet GNOME Web is just about brought to its knees by it. [19:36] hahahahahahaha [19:38] So yes indeed, GNOME Web is *almost* usable under Valgrind, and crashes with SIGTRAP when run directly. [19:38] Whether that's because it's just so painfully slow I interrupted it too soon is TBD [19:39] oh and also webkit is still building [19:41] interesting, bwrap is involved when running GNOME Web without Valgrind [19:41] but it doesn't get involved when running with Valgrind [19:42] so I think this thing's faking me out [19:42] arraybolt3: I found the issue. [19:43] At least for QtWebEngine-based browsers. [19:43] what is it? [19:43] Wanna confirm that running export QTWEBENGINE_DISABLE_SANDBOX=1 works? [19:43] sure [19:43] Could potentially not work for WebKit, although that could be a different error entirely. [19:43] Works over here, Falkon now loads. [19:44] nice find [19:44] \o/ [19:44] I bet that's why GNOME Web works under Valgrind, it's probably disabling sandboxing when it detects Valgrind. [19:44] So, here's the deal on that. [19:44] We're using an old QtWebEngine; we're a version behind. [19:45] mitya57 is sick and lisandro is without power until the weekend, so, well, I become the de-facto Qt 5 maintainer in Ubuntu and Debian, just going off of co-maintainership. :P [19:46] I'm willing to bet that updating to the latest QtWebEngine will do something. This is too big of an issue for them not to notice. [19:46] So, the internal Chromium right now is 108.0.5359.124, the new one would be 119.0.6045.123 :P [19:47] tsimonq2: well hold on now, I have an idea. If this is sandboxing related, I don't think it's going to help to upgrade QtWebEngine. It might, but I doubt it. [19:47] Because there's a sandbox in both places, and disabling it seems to fix it in both places [19:47] (both QtWebEngine and WebKit) [19:47] If that's the case, we *may* be up against a kernel bug. [19:48] NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo [19:48] So are there any other sandboxed apps you can try to confirm? [19:48] * arraybolt3 installs Flatpak and tries some hackery [19:48] WebKit doesn't have Chromium does it [19:49] nope [19:49] WebKit is a fully independent browser engine (well, almost fully independent, Blink/Chromium is based off of it or was long ago) [19:49] hah so https://qt-kde-team.pages.debian.net/images/qt5_build_deps.png webview depends on webengine which depends on webchannel :P [19:49] but both webkit and webengine depend on webchannel [19:49] it might be in webchannel... [19:50] mmm, doubt it from the GDB backtraces we got yesterday [19:50] the failure was in a destructor within QtWebEngine itself for Falkon, and in something in glib called from WebKit in Epiphany [19:50] IIRC anyway, the screenshots are up above [19:51] I'm installing Firefox as a Flatpak currently since bwrap looked like it might have had something to do with the issues and I know Flatpak uses bwrap under the hood [19:51] * tsimonq2 sends a qtwebengine to experimental [19:52] btw aren't Flat [19:52] pak's inaccurate progress meters awesome? https://i.imgur.com/9m1MELl.png [19:52] Like 146.5 MB vs 156.8 MB, ok I get it, but 17.8 KB / 333.4 MB O_O [19:53] sigh, Flatpak'd Firefox works [19:56] Confirmed, disabling the sandbox on Epiphany works even without Valgrind. [19:57] had to use WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 to make it work 🤪 [19:58] interestingly a different WebKit-based browser, "surf", works just fine with sandboxing. [20:01] I have no idea if this is related: [20:01] 14:02 < ahasenack> beware, https://pastebin.ubuntu.com/p/98hftZCHBd/ crashes the kernel [20:01] 14:02 < ahasenack> https://gitlab.com/apparmor/apparmor/-/issues/346 [20:01] -ubottu:#lubuntu-devel- Issue 346 in apparmor/apparmor "kernel null pointer dereference loading an invalid AppArmor profile, regression since 6.1" [Opened] [20:01] 14:02 -ubottu:#ubuntu-security- Issue 346 in apparmor/apparmor "kernel null pointer dereference loading an invalid AppArmor profile, regression since 6.1" [Opened] [20:01] jinx :P [20:02] oh that might be similar [20:03] Lemme try an install with the kernel in proposed real quick... [20:04] I don't think it's related - Falkon launches just fine on 22.04 with kernel 6.2.0. [20:04] BTW, I have about 10 minutes left for right now. My car is in the shop so I'll need to go get that picked up. [20:04] hmm [20:04] source - I just ran it [20:05] I tried strace'ing both Falkon and Epiphany and didn't see a syscall in common that triggers the weirdnes [20:05] *weirdness [20:05] which I guess makes sense but... [20:05] [telegram] I was wondering about apparmor [20:08] 2023-12-19T20:07:38.091817+00:00 lubuntu kernel: [ 170.840872] audit: type=1400 audit(1703016458.083:45): apparmor="DENIED" operation="userns_create" class="namespace" info="User namespace creation restricted" error=-13 profile="unconfined" pid=2409 comm="qutebrowser" requested="userns_create" denied="userns_create" [20:08] 2023-12-19T20:07:38.091818+00:00 lubuntu kernel: [ 170.840934] traps: qutebrowser[2409] trap int3 ip:7f05a3c4cb13 sp:7ffed669c4d0 error:0 in libQt5WebEngineCore.so.5.15.15[7f05a1a29000+6931000] [20:08] Yuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuup. It's apparmor [20:08] [telegram] Boom [20:09] https://launchpad.net/ubuntu/+source/apparmor/4.0.0~alpha2-0ubuntu7 [20:09] [Alex Murray] [20:09] * Enable user namespace restrictions by default (LP: #2046477) [20:09] - d/p/u/userns-runtime-disable.patch: add logic to disable user [20:09] namespace restrictions if kernel lacks support [20:09] - debian/usr/lib/sysctl.d/10-apparmor.conf: set sysctl value to 1 and [20:09] -ubottu:#lubuntu-devel- Launchpad bug 2046477 in apparmor (Ubuntu) "Enable unprivileged user namespace restrictions by default" [Undecided, Fix Released] https://launchpad.net/bugs/2046477 [20:09] update comment to match [20:09] - debian/apparmor.service: run After systemd-sysctl.service [20:09] ahahahahaha [20:10] https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626 [20:10] so it IS a kernel bug [20:10] arraybolt3: apparmor =/ kernel tho :) [20:10] A specific upload did this. [20:10] so did this get implemented for 23.10? [20:10] looks like not [20:10] nah the upload says noble [20:11] release on 2023-12-15 [20:11] So, it's been like this for about 4 days. [20:11] but you're right, the trap always happens right after an audit failure for both Epiphany and Falkon. [20:11] So I guess the appropriate solution is to make AppArmor profiles for those particular apps? [20:12] anyway, I can file the bug [20:12] [telegram] That tracks. I noticed it over the weekend (re @lubuntu_bot: (irc) So, it's been like this for about 4 days.) [20:12] unless kc2bez wants to, tsimonq2 I think you said you're busy [20:12] (I ignored the apparmor thing thinking "yeah yeah you always are griping about things, AppArmor" :P) [20:12] [telegram] I think there was a bug you can pile on [20:12] ah right, I remember that [20:12] * tsimonq2 reaches out to my security team contact [20:17] See -members; tl;dr we need to start writing AppArmor profiles. [20:17] [telegram] If my brain is working correctly, there needs to be more profiles for all the browsers now. That seems tedious. [20:18] Yeah Dan, I just confirmed as such [20:18] AppArmor confinement is enabled by default anyway [20:18] [telegram] It would be much more than just browsers. (re @kc2bez: If my brain is working correctly, there needs to be more profiles for all the browsers now. That seems tedious.) [20:19] [telegram] Good point (re @RikMills: It would be much more than just browsers.) [20:20] [telegram] run # `reverse-depends src:qtwebengine-opensource-src` [20:20] [telegram] Ouch [20:21] [telegram] I would suggest people try some random apps from that to see if they are affected [20:22] [telegram] That is what I did yesterday [20:22] [telegram] digikam for example also crashes [20:22] Evolution also has issues according to someone there. [20:22] https://bugs.launchpad.net/ubuntu/+source/qutebrowser/+bug/2046844 (I overhauled the bug [20:22] -ubottu:#lubuntu-devel- Launchpad bug 2046844 in qutebrowser (Ubuntu) "AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP" [High, Confirmed] [20:23] * RikMills subs [20:23] basically since this was caused by AppArmor but intentionally, I set it to Critical/Won't Fix, then added known-affected apps and set them to Confirmed/High [20:23] Thus matching with the requirement for Critical, "Severely affects applications beyond the package responsible for the root cause" [20:25] I'm considering changing the apparmor one to Confirmed/Critical, since what if we need to roll the change back before release to have something usable? [20:25] I think that's the right way to go here, surely the work they did to find packages that needed help missed a lot. [20:26] [telegram] https://bugs.launchpad.net/ubuntu/+source/falkon/+bug/2046796 [20:26] -ubottu:#lubuntu-devel- Launchpad bug 2046796 in falkon (Ubuntu) "falkon crashed with signal 5 in _nl_make_l10nflist()" [High, Confirmed] [20:26] [telegram] ^^ was private. now public [20:29] and now marked as dupe since it's another Signal 5 SIGTRAP mess. [20:36] Considering the widespread effects this has, I put messages in #ubuntu-flavors and #ubuntu-devel asking people to contribute to the bug report. The more packages we can find and add AppArmor profiles to, the better. That way we won't have to deal with a broken release or have to beg for the AppArmor change to be reverted. [20:51] [telegram] *does a chaos and spins a custom Lubuntu 22.04.3 ISO as a general repair system [20:54] :q [20:54] oops [20:56] [telegram] arraybolt3 waves goodbye secretly :P [20:57] [telegram] lol [21:00] [telegram] Yeah, especially given that some upstream apparmor people work for Canonical, I don't think they'd like it at all if we asked for a revery [21:00] [telegram] *revert [21:02] [telegram] Curveballs happen, everyone. I don't like how this breaks so many things either, but let's be honest, it came at a pretty darn convenient time to be able to do this kind of work. If you've been around for long enough, you know that not everyone respects Feature Freeze and that's caused issues before. Last cycle was the XDG stuff, I'd imagine this cycle will be full of apparmor and installer stuff [21:09] Considering the level of disruption this may cause, it's still something to keep in the back of our heads (even if we do just start writing AppArmor profiles). People were furious when we chose to do something as simple as not ship Flatpak on the ISOs. If we break an entire class of highly useful AppImages, that could very well come back to bite [21:09] Canonical in a way. [21:10] I also wonder if this breaks Snaps :P [21:10] *downloads Element Desktop via Snap to find out* [21:12] ok, Element Desktop works, so at least there's that [21:31] [telegram] Flatpaks are too [22:07] hmm, /usr/bin/flatpak has the needed AppArmor profile, doesn't that propagate to apps that are installed under it? [22:07] Maybe not... [22:07] [telegram] not necessarily no [22:07] [telegram] consider snapped applications, even if snapd has the proper apparmor profile, the individual snaps need their own AppArmor profiles [22:07] [telegram] same for appimages [22:07] oof [22:08] [telegram]