20:00:30 <waldi> #startmeeting
20:00:30 <MeetBot> Meeting started Wed Oct 30 20:00:30 2024 UTC.  The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:38 <waldi> #chair bwh carnil
20:00:38 <MeetBot> Current chairs: bwh carnil waldi
20:00:44 <bwh> Hi
20:00:45 <carnil> hello!
20:00:45 <waldi> welcome to todays meeting
20:01:51 <waldi> #topic CVE in firmware-nonfree in stable
20:01:59 <waldi> carnil: you wanted to discuss this?
20:02:19 <carnil> yes, so let me summarize what the issue is
20:03:09 <carnil> We have abatch of CVEs which got allocated in Intel advisories, in which we get to know in which upstream version YYYYMMDD some CVEs get fixed, so we can easily track when fixes go into unstable. But now the question is how we want to handle those in context of stable.
20:03:41 <carnil> My feeling is that handling firmware-nonfree in lower suites then get risky to break things, and we in most cases do not even know wich exact firmware change is fixing a CVE
20:03:49 <bwh> This is also something the LTS team is trying to deal with, and the results have not been pretty
20:04:19 <carnil> For microcode updates the situation is easier as we can backport a version to the other suites by almost rebuilding the package, but that cannot work for firmware-nonfree as sometimes blobs get dropped
20:04:21 <bwh> I agree that we usually lack specific information about which version of which file fixed the CVE
20:05:08 <bwh> For LTS we also have a need to backport firmware to support newer kernel versions, which complicates this further
20:05:08 <waldi> how do other distributions handle that?
20:05:23 <carnil> so my proposal was to do nothing and ignore the CVEs for older releases, unless we get to know something has really a major impact, but this was the point we could discuss as I know we might have different views depending on which team looks at the issues
20:05:40 <carnil> (this is my summary and question to the topic)
20:06:57 <bwh> If we know roughly which files are involved, do you think it's worth askingwhoever submits updates to those files in linux-firmware?
20:07:12 <bwh> Or has that already been tried?
20:08:43 <carnil> bwh: I think I did in a handful cases tried to approach people upstream and got no answer from the Intel people, I was more lucky on questions on the Bluetooth stack, but not on firmware files
20:08:48 <carnil> but I might just have been unlucky
20:08:54 <bwh> OK
20:09:03 <waldi> do i get this right. intel submits updates to linux-firmware and later assigns CVE and just lists the version in the advisory for them?
20:09:43 <carnil> for the qustion from waldi, I think mostly we can say it is handled inconsistently as well in other distros. For instance for CVE-2022-40964 RedHat seems to have released updates, ubuntu still has "needs evaluation" and SUSE does not track it at all
20:10:22 <carnil> waldi: mostly correct yes, see for instance https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00766.html wher it only says:
20:10:28 <carnil> Intel® PROSet/Wireless WiFi drivers to mitigate this vulnerability will be up streamed by August 08, 2023.  Consult the regular open-source channels to obtain this update.
20:11:42 <carnil> so we have to go back to linux-firmware/20230804 as the upstream version containing all the fixes claimed
20:11:44 <bwh> For Intel specifically I guess we have security contacts there that might be able to give more detail
20:14:51 <carnil> bwh: so you suggest we should try to get https://security-tracker.debian.org/tracker/source-package/firmware-nonfree Intel answering which commits are relevant and then for a potential update just cherry-pick those which adds blobs, beeing careful to not remove any firmware? (almost all assigned CVEs are ever Intel related I think)
20:15:16 <bwh> yes
20:16:06 <bwh> I have to agree that we shouldn't upgrade the whole package for a security issue
20:16:38 <bwh> (We probably still need to do that in LTS when updating the kernel, but at least that would be a comparatively rare event)
20:18:16 <waldi> okay. so we ignore CVE by default and try to get more information from the vendor, usualy just Intel
20:19:05 <carnil> ok I can agree that we should give it another few tries to make it possible to identify then the specific commits, and if so then make targeted updates. And agreeing not to update the whole package to a newer version in stable, oldstable and maybe older.
20:19:22 <carnil> to me it sounds good, as well additionally with ignoring them for a start by default, pending further information from Intel
20:19:47 <waldi> #agreed we should give it another few tries to make it possible to identify then the specific commits, and if so then make targeted updates
20:19:49 <carnil> but we would need to make this clear as well to LTS contributin folks why we took this decision for the upper suites, so we can handle it consistently across the various teams down to LTS team
20:19:54 <waldi> #agreed not to update the whole package to a newer version in stable, oldstable and maybe older
20:20:18 <carnil> thanks a lot for the short discussion of it, was valuable and helpful!
20:21:33 <waldi> #topic #1086229 - linux-image-6.1.0-26-amd64: System don't boot the GUI
20:24:15 <carnil> I started to handle it, there are OOT, but with the attached lspci output, it might be the NIC drivers. It would be helpful to understand why GUI does not come up. What I did as well was looking on the regressions list if I find something related (but failed)
20:24:16 <bwh> I guess we need to ask for /proc/modules?
20:24:50 <bwh> to find out what the proprietary driver is
20:25:07 <waldi> and the provided log does not show anything about taints, so this either from an unrelated system or missing all those stuff
20:25:30 <waldi> yes, or a kernel log from the working system
20:25:38 <bwh> right, that too
20:26:15 <waldi> and also now idea what he means with "doesn't boot GUI"
20:26:47 <bwh> I would assume gdm/kdm/whatever doesn't start
20:26:52 <waldi> but this is a nvidia-system: "VGA compatible controller [0300]: NVIDIA Corporation GK208B"
20:26:53 <bwh> but it's worth asking
20:27:25 <bwh> yes but apparently working with nouveau
20:27:57 <bwh> unless that's from the broken state, and the actual problem is it needs nvidia which didn't get built for the new version
20:28:44 <carnil> which I was hoping this is the case, thus asked which dkms packages are installed (this though does not exclude it might have been installed around the package managment)
20:28:45 <waldi> as the kernel log was from this state, it is likely the lspci output is as well
20:29:28 <waldi> does nvidia stuff still works by replacing GL libs, which are then not longer compatible with anything else?
20:30:01 <bwh> carnil: So I think the information to ask for would be (1) log from working version (2) /proc/modules from working version (3) lspci from working version
20:30:53 <carnil> ok!
20:31:53 <waldi> #action carnil to ask for more information
20:32:25 <waldi> #topic #1085949 - Installer regression on ppc64el under PowerKVM
20:32:55 <bwh> This is the bug report that I split off last week. No new information there
20:33:23 <waldi> okay
20:34:07 <waldi> #topic #1086230 - linux: LTFS mount failure on ATTO H680 due to possible pm80xx driver SCSI length mismatch
20:34:49 <bwh> What even is LTFS?
20:35:31 <waldi> no idea
20:35:39 <waldi> https://en.wikipedia.org/wiki/Linear_Tape_File_System
20:35:45 <carnil> bwh: I noticed intially ot got reported here: https://github.com/LinearTapeFileSystem/ltfs/issues/484
20:35:59 <carnil> so asked to actually ask upstream
20:36:13 <bwh> Right, and you noted this wasn't even reported on a Debian kernel
20:36:16 <carnil> (upstream, maintainers of the pm80xx driver)
20:36:56 <bwh> So I think we should close this
20:37:48 <carnil> ok
20:37:51 <waldi> yes
20:37:58 <bwh> (-pve seems to be a Proxmox kernel that is based on *Ubuntu* kernel sources)
20:38:02 <carnil> fwiw, he posted the question upstream, but I do not see/find it in the lore archives
20:39:50 <carnil> but it's fine to close, I do not see we can make any action *unless* it's found to be an upstream issue and has to go back to 6.1.y
20:40:35 <waldi> can you handle that?
20:40:47 <carnil> yes ok!
20:41:03 <waldi> #action carnil to close the bug
20:41:08 <waldi> thx
20:41:40 <waldi> #topic #1086175 - linux-image-6.1.0-26-amd64: panic at shutdown with rootfs on RAID1 while initialy resyncing
20:43:17 <bwh> From the information give, it sounds like it ought to be easy to reproduce, and is fixed upstream
20:43:50 <bwh> I can take some time to try to do that
20:44:15 <waldi> #action bwh try to reproduce and see if fixed upstream
20:44:17 <waldi> thx
20:45:33 <waldi> anything else?
20:46:21 <carnil> I guess not fo today. We still need to followup with a 6.12-rcX upload to experimental and try to review the new config options, features, etc ...
20:46:28 <waldi> right
20:46:51 <bwh> I see there was an update on #1076372
20:46:55 <carnil> but we still have a bit of time until we have to move it to unstable (it = 6.12.y) and then continue updateing it for making it ready for trixie
20:47:22 <carnil> bwh: I closed as agreed in the last meeting, and shortly after Stephan followed up with:
20:47:43 <carnil> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076372#71
20:48:34 <bwh> From that information it seems like there might be 2 different bugs
20:49:13 <bwh> one affecting the Lexar SSD on 6.10+, the other affecting the Kingston SSD on 6.1
20:49:32 <bwh> s/6.10/6.5/
20:50:27 <bwh> I don't know what to do next
20:51:04 <carnil> would it be an option:
20:51:20 <carnil> ask if able to reporduce any of those with the respective upstream versions
20:51:41 <carnil> 6.1.114 for the 6.1.y affecting one, and ask to test for the second 6.11.5, mainline and
20:52:14 <carnil> then report the issues on the upstream lists (though which subsystems and lists?)
20:53:31 <bwh> yes
20:53:59 <bwh> Since we don't patch nvme, I'm not sure we even need to ask to test upstream first, but I suppose it will be preparation for testing candidates fixes from upstream
20:55:01 <carnil> ok I guess we have a next action for that
20:55:51 <waldi> #topic aob
20:55:57 <carnil> if nobody feels I'm getting to be the bottleneck, then I take it as acktion to ask and report it then to the nvme subsystem maintainers
20:56:07 <carnil> s/acktion/action/
20:56:17 <waldi> #action carnil to work on #1076372
20:56:26 <waldi> anything else?
20:56:39 <bwh> Nothing from me
20:56:46 <carnil> nothing from me
20:56:47 <waldi> who wants to chair next week?
20:57:30 <bwh> It's my turn
20:57:39 <waldi> #action bwh to chair the next meeting
20:57:49 <waldi> thank you for joining everyone
20:57:53 <waldi> #endmeeting