[11:26] <dikonoor> amurray: This is on https://ubuntu.com/security/CVE-2022-2327. I am trying to understand which are the kernel versions that are impacted. There is a note in this that says - 'initial investigation indicates that this likely only affects
[11:26] <dikonoor> 5.10 and earlier, but not as far back as 5.4. But everything about
[11:26] <dikonoor> this issue is unclear.'
[11:26] <dikonoor> Are there any more updates on this? Or information on what is the impacted version
[11:28] <dikonoor> We had discussed about this and two other CVEs few days back > https://irclogs.ubuntu.com/2022/08/17/%23ubuntu-security.html and you had mentioned that the fixes for these CVEs might be available in the 29th Aug update. I see that there's a new version of the kernel namely 5.4.0-125 out but the CVEs don't have updates. So I am not able to figure out if the fixes for these have gone in or not.
[11:29] <dikonoor> The 3 CVEs are https://ubuntu.com/security/CVE-2022-1012, https://ubuntu.com/security/CVE-2022-2327 and https://ubuntu.com/security/CVE-2022-36946. I am on Ubuntu 20.04 , kernel 5.4.0 and I am trying to figure out which are the impacted ones and which of the fixes are available.
[11:37] <amurray> dikonoor: so you can see for 2 of those they are marked as 'needed' for focal (20.04) so you should assume they are affected and not yet patched - it looks like 2022-2327 is still waiting to be triaged by the kernel team (basically where they go looking to see if they have the affected commit in the various ubuntu kernel git trees)
[11:40] <dikonoor> amurray: So I guess this means none of the 3 are part of the update that happened yesterday?
[11:40] <dikonoor> Especially the first 2. Third one as you mentioned is not yet triaged
[11:43] <amurray> dikonoor: it looks like 2022-36946 is in https://launchpad.net/ubuntu/+source/linux/5.4.0-126.142 which is currently in focal-proposed so will be in the next stable kernel release
[11:44] <dikonoor> amurray: Thanks. I believe that would be after 3 weeks. So mostly around 19th Sept I assume
[12:03] <amurray> dikonoor: yep https://kernel.ubuntu.com/
[12:05] <dikonoor> amurray: Thanks!
[13:27] <luna__> Fedora will discuss what they are gonna do about the Security panel in around 20-30 minutes
[14:24] <luna__> decided to not hide it and helped give feedback to make it better
[19:05] <hggdh> folks, are you aware of bug 1988119? I understand laney took it off at the moment; but I am not sure what is the actual problem (apart from unattended-updates not restarting systemd-resolved)
[19:06] <sarnold> aware of, yes; root-caused, no
[19:11] <hggdh> thanks. We neded up with a sev 1 at Azure :-)
[19:15] <sarnold> an exciting time :(
[20:59] <question2> how do i make my live usb stick read only and with only one partition?
[21:00] <question2> i do sudo sha256sum /dev/sdb
[21:00] <question2>  and i expect it to be the same
[21:03] <sarnold> question2: that sounds tailor-made for https://manpages.ubuntu.com/manpages/jammy/en/man8/veritysetup.8.html
[21:04] <question2> what is that?
[21:05] <question2>  xubuntu 18.04.5 is still like that but xubuntu 22 is not anymore
[21:05] <sarnold> dm-verity provides for read-only hash-verified filesystems
[21:05] <question2> but my iso is written with dd
[21:05] <question2> !
[21:07] <question2> does dm-verity change my iso?
[21:07] <sarnold> question2: wait, what problem are you trying to solve?
[21:08] <question2> i want it to be tamper evident
[21:08] <sarnold> what is "it"?
[21:08] <question2> write the iso with dd to the usb stick
[21:08] <question2> hash the entire usb stick and expect always the same value
[21:09] <question2> xubuntu 18.04.5 is still like that but xubuntu 22 is not anymore
[21:12] <Eickmeyer> question2: if it makes you feel any better, the image verifies itself when you go to run it.
[21:14] <question2> ...
[21:14] <question2> how do i google that?
[21:16] <sarnold> question2: ah, so, if I've understood you correctly -- you've written an arbitrary ISO to a memory stick. you read the memory stick back and get a different sha256sum. you're curious how you can get the same value back every single time?
[21:17] <sarnold> question2: I believe the hardware doesn't guarantee this sort of repeatability, and I don't know why. I'd expect that you get the same sha256sum for any specific ISO that you write to the stick, every time you compute it, but I don't think it necessarily matches the data you wrote to the stick
[21:20] <question2> it works
[21:20] <question2> i know
[21:21] <question2> if you make dd if=xubuntu.18.04.5 of=/dev/sdX
[21:22] <question2> and you boot once from that stick
[21:22] <question2> if you then make sudo sha256sum /dev/sdX 
[21:22] <question2> at anytime
[21:23] <question2> it will be the same!
[21:25] <question2> but if you do :  dd if=xubuntu.22 or mint of=/dev/sdX
[21:25] <question2> it does not work anymore, because there is a writeable partition
[21:30] <question2> anyway thanks