[09:20] <SvenKieske> hi there, I was referred here from the "ubuntu-kernel" channel. I just wanted to ask if "linux-generic-hwe-20.04-edge" will get the update for "linux-generic-hwe-20.04-edge"? the metapackage seems not to be updated (yet)?
[09:21] <SvenKieske> sorry, c&p error, I meant if the hwe-edge kernel will get the update for https://ubuntu.com/security/CVE-2022-0847
[09:22] <SvenKieske> ah, and if you don't mind, what does "Does not exist" even mean, on these CVE pages? I really couldn't figure that one out. All help would be highly appreciated, thanks in advance :)
[09:29] <amurray> Does Not Exist means that a given packaged is not published in a particular Ubuntu release - so as you can see this kernel is superceded by the linux-hwe kernel so you should use that one instead as linux-hwe-edge will not be updated for this or other CVEs
[09:29] <amurray> s/packaged/package/
[09:34] <amurray> ah I see I was looking at the wrong package name - linux-generic-hwe-20.04-edge comes from the linux-meta-hwe-5.13 source package - and this has already been patched (see linux-hwe-5.13 on the CVE page)
[09:34] <amurray> tracking which kernel package is built from which source is a bit of a fine art
[09:35] <SvenKieske> yeah
[09:35] <SvenKieske> but I was just informed in #ubuntu-kernel, that "hwe-edge" in general receives no security updates at all, which is good to know, too..
[09:36] <SvenKieske> I still find it weird, that the patch seems to be in git (but maybe I'm looking at the wrong git): https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?h=hwe-5.13&id=438da6e5c849ffe553fc15379471bf331346c3d2
[09:37] <SvenKieske> nvm, that's "hwe", not "hwe-edge"...args..ubuntu has too many kernel variants.. (for my peculiar usecase). anyway, thanks!
[09:39] <JanC> maybe the -edge kernel shouldn't be in 'main' if it is not officially supported...
[16:40] <LocutusOfBorg> mdeslaur 	
[16:40] <LocutusOfBorg> The specific flaw exists in bionic and focal, but is not
[16:40] <LocutusOfBorg> currently exploitable due to lack of a flag that was introduced
[16:40] <LocutusOfBorg> in kernel 5.8. The flaw will be fixed as part of the next round
[16:40] <LocutusOfBorg> of bionic and focal kernel updates in case some other way of
[16:40] <LocutusOfBorg> exploiting it is discovered in the future.
[16:40] <LocutusOfBorg> mdeslaur, ^^
[16:41] <LocutusOfBorg> speaking of CVE-2022-0847
[16:41] <LocutusOfBorg> I checked on focal
[16:41] <LocutusOfBorg> and I exploited my own machine...
[16:41] <LocutusOfBorg> nevermind
[16:41] <LocutusOfBorg> Linux Unimatrix08-Focal 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[16:41] <LocutusOfBorg> :)
[17:30] <mdeslaur> yeah, that's the HWE kernel, and that one got an update
[17:30] <mdeslaur> I'll clarify in my note
[17:49] <LocutusOfBorg> actually was my fault
[17:49] <LocutusOfBorg> I forgot about hwe kernel
[17:55] <mdeslaur> someone else asked me the same thing, so clarifying the note is worth it
[18:01] <LocutusOfBorg> oh ok :D
[20:51] <ricotz> mdeslaur, hi, fyi https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-impish-7.2&id=c17b727d4ec5bc20678122303ca118ea8f7c5e3d
[20:52] <ricotz> afaict lgw01 builders were capable, but lcy02 are not :(
[20:53] <ricotz> mdeslaur, also https://launchpad.net/ubuntu/+source/libreoffice/1:7.2.6-0ubuntu0.21.10.1
[20:54] <mdeslaur> ricotz: oh! that's why that was failing...thanks for the hint!
[20:54] <mdeslaur> ricotz: I saw the new version in -proposed, so I'll rebuild mine based on it
[20:55] <ricotz> mdeslaur, is there really another rebuild for impish needed?
[20:55] <mdeslaur> ricotz: it needs to go into the -security pocket so it gets installed with unattended-upgrades
[20:56] <mdeslaur> ricotz: to go in the -security pocket, it needs to be built with -updates disabled
[20:56] <ricotz> mdeslaur, so using the currently running build is not an option?
[20:56] <ricotz> I see
[20:56] <mdeslaur> ricotz: the -security vs -updates split is annoying
[20:56] <ricotz> mdeslaur, better just pick the build fix for 7.2.5 then?
[20:57] <ricotz> still why the rebuild needed?
[20:57] <ricotz> expat isn't statically linked
[20:58] <mdeslaur> because if it builds against -updates, it may get dependencies that exist only in -updates
[20:58] <mdeslaur> which would render it uninstallable when only -security is enabled
[20:59] <ricotz> ok, please use 7.2.5 then
[21:00] <mdeslaur> why 7.2.5 instead of 7.2.6?
[21:00] <ricotz> to respect the SRU process?
[21:00] <mdeslaur> I'll wait a week for 7.2.6 to get released
[21:00] <mdeslaur> I'm in no hurry for the security updates, it can wait
[21:02] <ricotz> alright
[21:03] <ricotz> mdeslaur, please feel free to ping in such occasions
[21:04] <mdeslaur> ricotz: if might be simpler to have the SRUs be built without -updates enabled in the future, so they can simply be copied to -security
[21:04] <mdeslaur> we can discuss it next time there's an update to do, either an SRU or a security update
[21:06] <ricotz> ack, as long there is nothing vital in -updates/-proposed
[21:07] <ricotz> e.g. glib/gtk3/qt5 updates can be runtime deps
[21:08] <mdeslaur> yeah, if there is, I have to rebuild them in -security
[21:08] <mdeslaur> happens once in a while
[21:09] <ricotz> this won't help if the tests or autopkgtests are failing
[21:09] <mdeslaur> what do you mean?
[21:11] <ricotz> I mean if a library dependency is fixing runtime issues which are affecting the results of tests/autopkgtests you would need those newer versions
[21:11] <mdeslaur> yes, and in which case I would rebuild then as no-change rebuilds in the -security pocket
[21:12] <ricotz> but the package would fail to build
[21:13] <mdeslaur> if libreoffice needs the newer glib from -updates to pass the autopkgtests, I need to first build glib in -security, release it, then I can build libreoffice in -security
[21:13] <mdeslaur> what would fail to build?
[21:13] <ricotz> alright
[21:13] <ricotz> "make check" is fatal on amd64/arm64
[21:15] <ricotz> I don't remember seeing this in the past, but I usually build/test with -updates/-proposed
[21:16] <mdeslaur> yeah, as I've said, I really hate the -security/-updates split, but around 30% of our customers run with -updates disabled, and for the rest, unattended-upgrades won't pull stuff from -updates
[21:17] <mdeslaur> so the only way for users to get security updates is to have stuff in the -security pocket, built with -updates disabled
[21:18] <mdeslaur> and when that doesn't happen, we get pinged
[21:18] <ricotz> I understand, just indicating possible ill effects
[21:19]  * mdeslaur nods