13:02:03 <jki> #startmeeting CIP IRC weekly meeting
13:02:03 <collab-meetbot> Meeting started Thu Aug 21 13:02:03 2025 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:03 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:02:03 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
13:02:10 <jki> #topic AI review
13:02:23 <jki> - draft CVE handling process for CIP kernel [Jan]
13:02:38 <jki> just shared a draft with the core group
13:02:53 <jki> thanks for first feedback already, still need to read :)
13:02:58 <pave1> Yep, you have some replies :-).
13:03:15 <pave1> Not sure why we are talking about CVEs in the first place.
13:03:23 <jki> plan would be to put something on the wall during out Summit next week, then discuss
13:03:33 <pave1> For kernel, CVEs are just another identifier for stable kernel patches.
13:03:44 <jki> right
13:04:12 <jki> will also try to make that clear
13:04:38 <pave1> So you'll get stuff like "CVE-1"  for kernel, and then have "CVE-2" that reverts "CVE-1". Fun :-).
13:04:47 <jki> still, we have our tracker list, and we already heard more than once that it is considered very valuable
13:05:18 <jki> everything an happen, but I would not expect that to happen with every second CVE ;)
13:05:32 <pave1> This will be with about 1% of them.
13:05:47 <jki> examples always welcome
13:06:13 <jki> also to document where information is lost - and think about how annotation needs to be to reduce that risk
13:07:32 <jki> btw, no one expects upstream or the CIP kernel to be perfect in this, we should "just" apply best practices
13:08:05 <jki> ok - please provide further feedback that should go into the discussion on Thursday upfront
13:08:15 <jki> or speak up then ;)
13:08:21 <jki> no other AIs on my list
13:08:31 <pave1> I'm not sure what the goal here is.
13:08:54 <pave1> We don't _want_ to have 0 CVEs for cip-4.4 kernel...
13:08:57 <jki> document out process for paper work, would be one thing
13:09:10 <jki> we will never have 0 CVEs in anything
13:09:26 <pave1> ...because that would mean buggy kernel.
13:09:49 <jki> please do not expect additional pressure on maintainers from writing down how things work
13:10:05 <patersonc> It's not only about the "CVE". It's about making sure that we are fixing known bugs in our kernels right?
13:10:39 <jki> patersonc: you first of all asked about CVEs ;)
13:11:00 <pave1> I guess we should talk in person.
13:11:03 <jki> but, yes, bug handling in general is important too
13:11:11 <patersonc> I did - but it's just because we have tooling tracking the CVEs, we don't have tooling tracking every upstream fix
13:11:34 <patersonc> Although every upstream fix is a CVE now..
13:11:42 <pave1> patersonc: I believe priority is a) not add new bugs, and b) given a), fix some bugs.
13:11:49 <jki> in theory, surely not in practice
13:12:29 <jki> and some bug fixes really don't deserve CVEs, but they should still be in stable
13:12:53 <pave1> patersonc: Fortunately not every upstream fix. When things are applied to _stable_, they will get CVE identifier.
13:13:14 <pave1> patersonc: If it does not apply to stable (patch failed), I'd expect it is just dropped.
13:13:41 <jki> paveL: functional fixes that do not address security aspects will not get CVEs (or will get them revoked)
13:14:26 <pave1> jki: I believe the policy is "if it is a bug fix it gets an CVE" and then "if someone tries to revoke the CVE we may do that".
13:14:55 <pave1> jki: stable team is pretty clear about not deciding about security when assigning CVEs.
13:16:56 <jki> pavel: already due to the fact that some fixing commit may pull preperatory commits you do not have a 1:1 between stable commit and CVE
13:17:19 <pave1> jki: I'm not claiming 1:1 between stable commits and CVEs.
13:17:35 <jki> but I think we should really continue this on Thursday :)
13:17:36 <pave1> jki: I'm saying that "admin can crash his own machine" will get an CVE.
13:17:43 <pave1> jki: yes.
13:18:08 <jki> 5
13:18:10 <jki> 4
13:18:12 <jki> 3
13:18:13 <jki> 2
13:18:15 <jki> 1
13:18:16 <jki> #topic Kernel maintenance updates
13:18:32 <uli> i'm working on 4.4
13:19:09 <pave1> I'm reviewing 6.12.42 and .43.
13:19:09 <masami> This week reported 118 new CVEs and 6 updated CVEs.
13:19:24 <iwamatsu_> I am reviewing 6.12.42. and I released 510.y-cip and 6.1.y-cip.
13:19:58 <pave1> ...and renesas patches. SPI and camera, camera is 55 patches.
13:21:23 <jki> anything to add?
13:21:36 <jki> 5
13:21:37 <jki> 4
13:21:39 <jki> 3
13:21:41 <jki> 2
13:21:43 <jki> 1
13:21:44 <jki> #topic Kernel release status
13:21:55 <jki> everything green
13:22:12 <jki> any issues ahead?
13:22:32 <jki> 5
13:22:34 <jki> 4
13:22:36 <jki> 3
13:22:37 <jki> 2
13:22:39 <jki> 1
13:22:42 <jki> #topic Kernel testing
13:23:14 <patersonc> Arisu's KernelCI PR has now been merged, adding initial test support for CIP kernels
13:23:25 <patersonc> Hopefully it will push out to production soon
13:23:41 <patersonc> There are some known issues with booting the arm32 devices, but this seems to be a kernel config issu
13:24:29 <patersonc> I'll update more on the specifics next week
13:26:17 <jki> more test topics?
13:26:35 <patersonc> Not from me
13:27:21 <jki> 5
13:27:23 <jki> 4
13:27:25 <jki> 3
13:27:26 <jki> 2
13:27:29 <jki> 1
13:27:31 <jki> #topic AOB
13:28:07 <jki> first of all: we have the mini summit next week, this time, thus no irc meeting
13:28:32 <jki> skip, or should we shift?
13:29:35 <uli> skip it, imo
13:29:39 <patersonc> +1
13:29:40 <pave1> I believe skip. We'l have enough meetings next week :-)
13:29:44 <iwamatsu_68> +1
13:29:55 <jki> exactly :)
13:30:30 <jki> but... should he have a lunch meetup as kernel WG again?
13:30:44 <jki> who will be there at all?
13:30:49 <uli> o/
13:30:51 <patersonc> o/
13:30:52 <pave1> o/
13:31:18 <iwamatsu_68> I am not there...
13:31:37 <jki> if you like to meet, I would suggest the Wednesday lunch slot
13:31:58 <jki> meet at CIP booth
13:33:01 <jki> ?
13:33:13 <patersonc> Sounds tasty
13:34:42 <jki> ok, be there if you like and can
13:34:54 <jki> any other topics for today?
13:35:47 <jki> 5
13:35:49 <jki> 4
13:35:51 <jki> 3
13:35:53 <jki> 2
13:35:55 <jki> 1
13:35:57 <jki> #endmeeting