13:05:45 <pave1> #startmeeting CIP IRC weekly meeting
13:05:45 <collab-meetbot`> Meeting started Thu Feb 29 13:05:45 2024 UTC and is due to finish in 60 minutes.  The chair is pave1. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:45 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:05:45 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
13:05:55 <pave1> #topic AI review
13:06:02 <pave1> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:06:14 <jki> now I just found one :D
13:06:27 <jki> no progress in the past week, sorry
13:06:36 <pave1> No problem. Other AIs?
13:06:37 <pave1> 3
13:06:38 <pave1> 2
13:06:38 <pave1> 1
13:06:48 <pave1> #topic Kernel maintenance updates
13:07:03 <uli> i'm backporting for 4.4
13:07:06 <pave1> I am reviewing 6.1.79 and .81.
13:07:09 <masami> This week reported 130 new CVEs and 21 updated CVEs.
13:07:18 <pave1> Yep, about that.
13:07:20 <jki> oh, wow
13:07:23 <jki> that many
13:07:28 <pave1> I don't believe Greg is acting in good faith here.
13:07:39 <pave1> He copies changelogs verbatim with zero analysis. Not even making it
13:07:44 <pave1> sentences or stripping irrelevant information. Sometimes he pastes "In
13:07:49 <pave1> the Linux kernel, the following vulnerability has been resolved:"
13:07:53 <pave1> before the changelog. Result is basically DoS on people that try to be
13:07:56 <pave1> carefull and not pick everything from stable. Spamming us is colateral
13:08:00 <pave1> damage. I don't think arguing with him makes sense. This should be
13:08:03 <pave1> escalated.
13:08:11 <masami> we can see lots of CVE numbers are reserved at git repo https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/reserved
13:08:12 <pave1> So... yes, wow :-(.
13:08:48 <jki> so, what is the damage for us now?
13:08:51 <pave1> CVE-2023-52466 is example of bad cve.
13:08:53 <jki> already
13:09:08 <pave1> CVE-2023-52437 is another one.
13:09:10 <iwamatsu__> I am reviewing 6.1.79
13:09:29 <pave1> Well... it will make our CVE tracking useless.
13:10:23 <jki> but that was questionable from a technical perspective already, back then because too many fixes had no number
13:10:38 <jki> at least that reason is kind of "gone" now...
13:10:42 <jki> but, yeah
13:11:19 <pave1> We should simply ignore any CVE from Greg. But it would be better to escalate through Neal and LF,
13:11:26 <pave1> because this will harm whole community.
13:12:16 <jki> can you write up some concrete points regarding that?
13:12:26 <jki> I will try, but I need input
13:12:39 <pave1> Ideally, security people should do that.
13:12:51 <pave1> Because they are supposed to know what CVEs look like.
13:14:08 <jki> I will try to chat with our own folks on that
13:14:20 <pave1> I can try to provide input, but Masami's "New CVE entries this week" already has plenty.
13:14:32 <jki> yep
13:14:54 <pave1> I don't believe "the patch applied okay, so just paste its changelog into CVE" is what security community expects.
13:15:35 <pave1> Ok, anything else?
13:15:36 <pave1> 3
13:15:37 <pave1> 2
13:15:38 <pave1> 1
13:15:46 <pave1> #topic Kernel release status
13:15:57 <pave1> 4.19-rt is late.
13:16:13 <pave1> v4.19.307-rt133-rc1 exists, so I guess we should coordinate cip & rt release when that is out.
13:17:26 <pave1> IIRC others are on track.
13:17:33 <pave1> Anything else?
13:17:34 <pave1> 3
13:17:34 <pave1> 2
13:17:34 <pave1> 1
13:17:37 <jki> has upstream 4.19-rt any issue?
13:18:24 <jki> (BTW, CVE-2023-52437 is on rejected by now)
13:18:58 <jki> my question aims at if we as CIP should/could do something actively, or if we simply wait a bit more
13:19:33 <pave1> Not that I know of. I'd need to take second look. I believe it is normal "-rc1 before release".
13:20:01 <jki> ok, then let's continue
13:20:19 <pave1> I believe we should tell Linux Foundation that this does not work for us. We may be in good position to influence Greg.
13:21:20 <jki> ack, but we will have to explain the reasons sufficiently
13:21:23 <pave1> It is likely that there's someone at cve.org who will realise this is bad, so waiting would work, but we can't be sure.
13:21:38 <pave1> It is a spam. Greg is not doing any analysis.
13:22:21 <pave1> So now either we have to do the analysis, or we can simply ignore it.
13:22:38 <pave1> And given it has CVE numbers, our customers likely don't expect us ignoring it.
13:23:21 <jki> understood
13:23:40 <jki> already chatting with our CERT in parallel
13:23:58 <pave1> Good :-).
13:24:01 <pave1> Move on?
13:24:05 <jki> ack
13:24:07 <pave1> 3
13:24:07 <pave1> 2
13:24:08 <pave1> 1
13:24:12 <pave1> #topic Kernel testing
13:24:38 <patersonc> I don't think I've got anything to share this week
13:24:49 <arisut> no updates from me
13:25:06 <jki> what's the deal with the kernelci bot messages now?
13:25:21 <jki> they are still there or back, aren't they?
13:25:33 <patersonc> I'm checking with them already
13:25:41 <patersonc> Maybe the merge request hasn't hit production yet
13:25:43 <arisut> what message can you give a link?
13:26:09 <patersonc> Some were sent to cip-dev today
13:26:26 <jki> exactly - is that intentional?
13:27:39 <patersonc> The change to stop it has been merged, but it could be that kernelci's production instance hasn't been updated to include it yet
13:28:14 <pave1> So I guess it should fix itself within week or so, and we can revisit next meeting?
13:28:37 <patersonc> yep
13:28:42 <pave1> Good.
13:28:43 <jki> that's fine, yes
13:28:49 <pave1> I took a look at squad.
13:29:41 <pave1> 
13:29:46 <pave1> irc is acting funny.
13:30:05 <pave1> Squad triggers automatically at push?
13:30:34 <pave1> And we need to look if all tests are finished, and that results are either pass or xfail?
13:31:21 <patersonc> When a build or test job is completed in gitlab CI, it notifies squad
13:33:10 <arisut> patersonc any progress on sending results to squad from kernelci?
13:33:32 <patersonc> I haven't had a chance to look yet, sorry
13:34:20 <jki> ok - more testing topics?
13:34:28 <pave1> Ok, so it is "check gitlab page for green crosses, then squad for pass or xfail"?
13:34:53 <patersonc> Yea
13:35:05 <patersonc> squad will indicate the results of the actual test cases
13:35:13 <pave1> Ok, I guess I'll have a chance to try it soon.
13:35:14 <patersonc> gitlab only shows if the lava job got to the end or not
13:35:38 <pave1> Ok, move on?
13:35:41 <pave1> 3
13:35:41 <pave1> 2
13:35:42 <pave1> 1
13:35:59 <pave1> #topic AOB
13:36:13 <pave1> Anything else?
13:36:15 <pave1> 5
13:36:21 <pave1> 4
13:36:22 <pave1> 3
13:36:22 <pave1> 2
13:36:23 <pave1> 1
13:36:31 <pave1> #endmeeting