13:01:40 <jki> #startmeeting CIP IRC weekly meeting
13:01:40 <collab-meetbot`> Meeting started Thu Mar  7 13:01:40 2024 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:40 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:40 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
13:01:45 <jki> #topic AI review
13:01:50 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:02:05 <jki> no progress - should take a day off...
13:02:13 <jki> - migrate kernelci bot reports away from cip-dev [Chris]
13:02:32 <patersonc> A mistake was made. Should be fixed soon
13:02:40 <jki> ok, great
13:02:44 <jki> other AIs?
13:02:54 <jki> 5
13:02:55 <jki> 4
13:02:57 <jki> 3
13:02:58 <jki> 2
13:03:00 <jki> 1
13:03:02 <jki> #topic Kernel maintenance updates
13:03:46 <masami> This week reported 277 new CVEs and 10 updated CVEs.
13:03:48 <uli> i pushed 4.4-rc, now reviewing 6.1.80
13:03:50 <pave1> I'm reviewing 6.1.79 & 6.1.81.
13:03:52 <iwamatsu__> I reviewd 6.1.79, and reviewing 6.1.80
13:03:59 <masami> I added a new script to cip-kernel-sec. which is called import_announce.py.
13:04:05 <masami> It gathers CVE information from https://git.kernel.org/pub/scm/linux/security/vulns.git/ .
13:04:08 <pave1> I'm still reviewing 4.4-st, I'll have some comments there.
13:04:57 <jki> masami: thanks for that work!
13:05:02 <pave1> CVEs: I believe we should stop looking at kernel CVEs until situation improves.
13:05:11 <jki> still unsure if it will help in the end :-/
13:05:20 <pave1> This is just a bad-faith spam from Greg.
13:05:21 <masami> this script will help us to track CVEs :)
13:05:55 <jki> I saw in some CVEs that there are now even commits listed
13:06:11 <jki> in that regard, tracking improves, no?
13:06:21 <masami> these CVEs are committed to NVD so we should take care of them :(
13:06:37 <pave1> How?
13:06:40 <masami> I think tracking is better than last week with new script
13:06:41 <pave1> Contest every single one?
13:06:54 <pave1> Talk to LF to fire Greg?
13:07:06 <pave1> Talk to NVD to stop taking thrash from Greg?
13:07:49 <masami> Some tools (poky's cve checkre) warn CVEs because they look NVD database.
13:07:50 <pave1> This will make maintaing 4.4 impossible, BTW.
13:08:08 <uli> how so?
13:08:23 <jki> <same question>
13:08:30 <pave1> Well, every single bugfix is going to be marked with CVE.
13:08:51 <pave1> Maybe 50% of them apply to 6.1, maybe 30 % to 5.10, maybe 20% to 4.19.
13:09:05 <pave1> So, for 4.19, 80% of fixes won't apply.
13:09:31 <pave1> And that will all have CVE numbers, because "numbering authority" did not do any analysis.
13:09:53 <jki> so, we are missing a lower boundary for the CVEs, version-wise?
13:10:05 <pave1> And we don't have manpower to analyse that, or to contest them.
13:10:23 <pave1> "Lower boundary"?
13:10:46 <jki> CVE applies to any kernel < 6.1.345, 6.6.23 etc.
13:11:07 <jki> but some may only apply to > 5.10.345
13:11:29 <jki> however the CVE will stick to all older kernels right now, that's at least my understanding
13:11:30 <pave1> So.. the bug exists in 3.6 to 6.8 kernels.
13:11:35 <jki> yes
13:11:48 <pave1> Fix is in 6.8, and we have backports to 6.1.
13:11:55 <pave1> It no longer applies to 5.10.
13:12:22 <pave1> For some bugs we have information when the bug was introduced, for some we don't.
13:12:25 <masami> Some CVEs don't have Fixes tag. That case we need to analyze them.
13:12:34 <jki> but then the question is if it actually makes sense / is needed for older kernels, and how to document that
13:12:53 <pave1> And where to get 10 engineers analysing that :-(.
13:12:56 <masami> Most CVE announce contains introduced commit information. so far.
13:13:24 <jki> we end up with CIP kernels that have tons of unfixed CVEs
13:14:17 <pave1> So if it actually has fixes tag and the patch applies to all the kernels that contain the buggy commit we are fine.
13:14:43 <pave1> Exactly. We'll have tons on unfixed "CVEs", even without security bugs.
13:15:11 <patersonc> How often do the new CVEs not have a lower version boundary?
13:15:34 <pave1> And I'm not a lawyer, but there's legislation pending which will say we need to care about CVEs.
13:15:59 <patersonc> Seems to me that the lower boundary should be set when the CVE is created? Isn't it essential info?
13:16:21 <jki> we as CIP are not in scope of that EU legislation
13:16:35 <jki> we as commercial CIP users are
13:16:37 <masami> This week 55 CVEs don't have introduced commit information.
13:17:18 <patersonc> masami: Okay so that's quite a lot
13:17:28 <patersonc> Does the information get added over time?
13:18:17 <masami> I check patch and original code for older kernels. it takes time..
13:19:15 <pave1> And we probably could check and find that >80% of "CVEs" are invalid.
13:19:32 <pave1> But that will take also take time.
13:19:51 <masami> that's true.
13:20:12 <jki> we have TSC next week - this shall be a prominent topic for it
13:20:28 <pave1> Yes please. That's a good place to solve this :-(.
13:20:50 <masami> I see. thanks.
13:20:55 <pave1> Relevant links --
13:21:15 <pave1> https://lwn.net/Articles/961978/ -- lwn explains that Greg is doing the spamming intentionally.
13:21:27 <pave1> https://amanitasecurity.com/posts/dear-linux-kernel-cna-what-have-you-done/ -- security researchers not being happy.
13:22:28 <masami> pavel: thank you for the links. I'll read.
13:22:38 <jki> thanks for the link
13:23:04 <jki> is that second one already covering what is happening the last two weeks?
13:24:04 <jki> if any one finds such statements elsewhere, please share as well
13:24:04 <pave1> I believe so. Problem did not exist two weeks ago.
13:24:12 <jki> ok
13:24:23 <jki> need to read carefully
13:24:48 <masami> That said "A quick count of the linux-cve-announce mailing list shows that over 200 CVEs were assigned in the first 4 days of operation, the majority of which have no demonstrated security impact."
13:25:23 <jki> yep, almost fresh - there are 800
13:25:28 <jki> good
13:25:36 <jki> or not...
13:25:42 <jki> other maintenance topics?
13:26:02 <uli> pave1: you said you had a comment on 4.4?
13:26:22 <pave1> I'm still reviewing the patches. I have a missing free at least.
13:28:58 <jki> anything else?
13:29:13 <jki> 5
13:29:14 <jki> 4
13:29:16 <jki> 3
13:29:17 <jki> 2
13:29:19 <jki> 1
13:29:21 <jki> #topic Kernel release status
13:29:43 <jki> ok, we have a couple of delays, let me check again
13:29:53 <jki> 4.4 is about to be released, after review
13:30:03 <jki> 4.4-rt as well?
13:30:12 <pave1> Yes.
13:30:26 <pave1> Other -rts should be up-to-date now.
13:30:34 <jki> linux-5.10.y-cip is late as well
13:30:45 <jki> by one day :)
13:31:28 <jki> iwamatsu no longer connected, it seems
13:32:05 <iwamatsu__> Yes, I am preparing release this week.
13:32:05 <jki> ok, then we move on
13:32:11 <jki> ah, perfect
13:32:19 <jki> good, rest was fine
13:32:29 <jki> 3
13:32:30 <jki> 2
13:32:32 <jki> 1
13:32:34 <jki> #topic Kernel testing
13:32:56 <patersonc> Pavel I saw your email about squad - sorry I haven't replied yet
13:33:18 <patersonc> I also have an MR for cip-core CI/testing to review on my todo list
13:33:58 <patersonc> Our new EC2 tag tracking seems to be working
13:34:12 <patersonc> So we have a better understanding of what project is running more CI
13:34:15 <pave1> patersonc: I'm starting to look at the squad before doing the releases, but don't mind being doublechecked for now.
13:34:21 <patersonc> I'll explain more in the TSC
13:34:28 <patersonc> Thanks pave1
13:36:36 <pave1> 
13:37:35 <patersonc> I think that's all I have this week
13:38:21 <jki> any other testing topics?
13:38:32 <sietze> I am working on an automated way to generate these test reports
13:38:51 <sietze> As a replacement of Chris's emails
13:39:19 <jki> sietze: cool - if that is possible
13:40:16 <pave1> It looked like the pages were now simple enough that we could understand and check them before release.
13:40:52 <pave1> I expect emails to be obsolete in month or so.
13:41:17 <sietze> Setting up the known issues also helped I guess
13:41:30 <pave1> Yes! :-)
13:42:02 <pave1> Now if I could have single green line "everything is okay in commit ABCD" I'd be happy.
13:42:13 <pave1> So far I'm checking gitlab to see if tests are done
13:42:23 <pave1> and then squad to see if there are any fails...
13:43:48 <jki> great to see this evolving!
13:44:03 <jki> further topics?
13:46:07 <patersonc> sietze: thanks for the update
13:46:15 <jki> 5
13:46:17 <jki> 4
13:46:19 <jki> 3
13:46:21 <jki> 2
13:46:24 <jki> 1
13:46:26 <jki> #topic AOB
13:46:41 <jki> anything else for today?
13:47:46 <jki> 5
13:47:48 <jki> 4
13:47:50 <jki> 3
13:47:51 <jki> 2
13:47:53 <jki> 1
13:47:55 <jki> #endmeeting