[06:22] <bittin__> no new podcast yet?
[06:23] <amurray> bittin__: hehe I am editing it as I type this - will be out in 30 mins or so ;)
[06:23] <bittin__> alright thanks :)
[06:40] <amurray> bittin__: it just went live https://ubuntusecuritypodcast.org/episode-165/
[06:40] <bittin__> amurray, perfect, will listen after i am done listening to this weeks BSD Now
[07:01]  * bittin__ is listening now
[12:36] <ebarretto> hank, hey, thanks again for reporting issues on our OVAL. I'm aware of those cases and I will try to give a higher priority to this
[14:16] <tomreyn> are there plans to ship these on ubuntu? https://lore.kernel.org/lkml/20220408195539.168011-1-john.allen@amd.com/ https://www.phoronix.com/scan.php?page=news_item&px=Zen-1-To-Zen-3-2022-AMD-ucode
[14:22] <rbasak> tomreyn: it's pretty normal for amd64-microcode to get updates
[14:23] <rbasak> As the Phoronix article says if they haven't released anything since 2019, then the current microcode packages are up-to-date apart from this recent release?
[14:25] <tomreyn> rbasak: yes, this would seem so. it's not *that* recent, the mailing list post was in early april, it's now late june and https://packages.ubuntu.com/search?keywords=amd64-microcode looks the same. i'm not sure that this really has security impact, though.
[14:26] <tomreyn> whereas: https://packages.debian.org/search?keywords=amd64-microcode
[14:27] <rbasak> tomreyn: maybe start by making sure a bug exists against the package?
[14:28] <rbasak> Then you'd be able to coordinate with anyone else interested
[14:29] <tomreyn> rbasak: i'll do so, thanks for the suggestion. i just hoped this would happen 'automatically' as part of an existing, and faster, process.
[14:29] <tomreyn> maybe my expectations are just bad.
[14:30] <rbasak> If we go too fast, then inevitably at some point there will be a bad microcode update that breaks users, and then users will complain that we didn't go slow enough or didn't do enough QA or whatever, and that they expect us to have process in addition to the manufacturer's release process even for binary blobs like these :-/
[14:31] <rbasak> So there has to be a balance.
[14:31] <rbasak> And that generally gets driven by some objective analysis that requires an actual case for the update rather than "it has a higher version number"
[14:41] <tomreyn> if a 2,5 months QA phase is happening with these microcodes somewhere in ubuntu-land (since most other distros have since shipped these) and this is why there are no readily available updates in ubuntu, yet, then i agree it *can* be worth waiting until it will be finished. i'm not sure that this is what's actually happening.
[14:42] <tomreyn> i agree it's good not to ship all blobs immediately, especially when there's not even any public statement about what they do.
[14:52] <rbasak> I don't think there's a formal QA phase. Just that trust that the update is good develops over time.
[14:53] <rbasak> And that since it's not necessarily a good thing to ship it immediately, generally a case has to be made that it's good to ship it to stable releases at all, before it actually happens.
[14:54] <rbasak> IIRC there have been microcode regressions in the past. I don't remember which manufacturer.
[14:54] <rbasak> It's hard to test since there are so many variations.
[14:59] <ebarretto> hank, so I've fixed the data on the CVE files instead of fixing the OVAL generation scripts, that should be enough to handle those specific cases for now. Give it a few hours to generate a new file and let me know if you find any new issues
[15:00] <tomreyn> I'm pretty sure there were regressions with the 2019 AMD ucode updates (thus the "really" package version). The April '22 one doesn't seem to have caused much uproar since.
[15:00] <tomreyn> rbasak: ^
[15:03] <hank> ebarretto: thanks!
=== ahasenack__ is now known as ahasenack