[14:45] Hey, I'm curious about how you get your upstream feeds for the USN and OVAL definitions, specifically for the Linux kernels on Ubuntu. Context is that we're considering the viability of building a 6.x kernel, but we want to know that we can get reliable metadata on which kernel CVEs affect our installed versions but as far as I can tell the versions are not included as metadata in the CVEs [14:45] themselves, and I'm assuming that you as a security team are having to manually triage all of them to create that metadata for the supported Ubuntu kernels - is that accurate? [14:57] grimmware: for the kernels, the CVE # is rarely in the patch, the sourcing of the CVE comes from several different sources. There is the OSS mailing list, reporters may researcher/report the vulnerability directly to us, mitre (if a researcher/reporter gets a CVE number from them), we have representative on the kernel security ml (which is actually rarely used as most kernel CVEs seem to get assigned after the patch is public), [14:57] and we coordinate as best we can with other distros [15:01] jjohansen: that is *really* helpful context, thank you for sharing! [15:03] grimmware: there are couple of other intermediary sources as well like ZDI who run pwn2own and run bug bounty programs [15:04] researches will submit stuff to them (usually as part of pwn2own), and then ZDI will forward it to us if they take us down in pwn2own ... [15:04] jjohansen: I think the really killer feature that we want parity with is the ability to simply know what vulns we have where by matching version metadata (so thank you to all of the team for your hard work on that!) [15:35] hmm I think it might make sense for us to wait for 23.04 and then we can just wholesale backport the pre-built package [15:35] and then just track USNs the same way that we already do [15:36] I mean I guess that commits us to a kernel roll-forward when 23.10 comes out but I *really* want id-mapped mounts on overlay2 :P [15:37] grimmware: 22.04 will eventually get 23.04's kernel thanks to HWE kernels [15:37] :O [15:37] my point is you won't need to do any backports of your own :) [15:37] sdeziel: do you know what the timescale for that is liable to be? [15:38] like, roughly at release or ~weeks ~months later? [15:40] grimmware: I don't know of any dates but it shouldn't be too long for 5.19 to be available for 22.04. You can readily install `linux-image-generic-hwe-22.04-edge` and if you use jammy-proposed, you'd get a 5.19 kernel [15:41] grimmware: eventually, 5.19 will move from hwe-edge to hwe [15:41] ! [15:41] 5.19 actually has the base set of features I need I think [15:41] and once 23.04 releases, the same deal will happen with its kernel [15:42] grimmware: this is documented in https://wiki.ubuntu.com/Kernel/LTSEnablementStack which doesn't mention 22.04 yet but the packages are available :) [15:42] sdeziel: awesome, thank you so much! [15:43] hey, my pleasure! [15:43] sdeziel: do you know if they typically come with like, the -aws flavours? [15:43] grimmware: HWE kernel are literally the next release kernel built for the previous LTS [15:44] jjohansen: gotcha [15:45] so once 22.10 was released, its kernel became available for 22.04, there could be a little delay due to the odd issue but it should get updated on the 3 week cadence [15:46] awesome [15:46] the other thing to note is once you opt into HWE you are on a rolling release kernel so once 23.04 is released, it becomes the new HWE kernel [15:47] grimmware: I don't know for the other flavors. For AWS, it seems that `linux-image-aws` is what keeps moving forward as Focal get's Jammy's 5.15 with it [15:47] sdeziel: that's interesting, I'll do a bit of research there [15:48] it could very well be here that the answer is "don't change anything and wait" [15:48] grimmware: I use `rmadison $pkg_name`. [15:48] sdeziel: TIL [15:49] grimmware: also, with HWE, you get the latest kernel available up to the next LTS at which point it stops moving forward. This means 20.04 + HWE will stop at 22.04 GA kernel (5.15) [15:53] yeah so looking at this bionic host `linux-image-aws` did indeed jump from 4.15 up to 5.3 and then 5.4 [15:53] I think this conversation has just saved me quite a lot of work