12:02:41 <jki> #startmeeting CIP IRC weekly meeting
12:02:41 <collab-meetbot`> Meeting started Thu Aug 17 12:02:41 2023 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02:41 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:02:41 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:02:49 <jki> #topic AI review
12:02:54 <jki> 1. create kernelci pipeline for buster images (arisut)
12:03:58 <jki> arisut: your isar-cip-core patch is related, I assume
12:04:08 <jki> so, still ongoing, right?
12:04:13 <arisut> i sended a mail to isar-cip for a patch fir adding buster, bookworm and bullseye
12:04:49 <arisut> Any prospect on merging time? Or questions?
12:05:19 <jki> I'm still wondering about the number of jobs we spawn, and if that is needed for every CI run
12:05:50 <jki> specifically as we seem to hit some wall at git.kernel.org around fetching tarballs
12:06:05 <jki> but let's follow up on the mailing list on that, ok?
12:06:59 <arisut> Yeah i see that, we cannot mirror it anymore?
12:07:32 <jki> we had issues with github - or was it gitlab? - in the past as well
12:08:20 <jki> see commit 73f779e067b75a7fbb09bdcf6f8744b41b3c1802
12:08:37 <arisut> Ok
12:08:39 <jki> "gitlab.com turned out to be too unreliable for fetching on-the-fly generated kernel tarballs in CI. Let's hope kernel.org will do better." - well...
12:08:55 <arisut> Other than that looks ok?
12:09:16 <jki> but even with that solved, the number of jobs also affects our AWS bill
12:09:49 <jki> and I would like to manage that according to our actual needs, that's why I was challenging the expansion
12:10:01 <arisut> But still isar-cip images need to be tested with the respective linux-cip kernel
12:10:32 <jki> sure, then may drop some other jobs we no longer need after adding your new ones?
12:10:34 <arisut> As we decided same as Debian is doing
12:11:42 <jki> again, let's resume the ML discussion thread, I can follow up after this meeting
12:11:45 <arisut> Buster with 4.19.y-cip bullseye with 5.10.y-cip and bookworm with 6.1.y-cip
12:11:50 <arisut> Ok
12:11:56 <jki> 2. draft press release about 6.1-cip (jan)
12:12:10 <arisut> Also one question I couldn't understand it, sorry
12:12:13 <jki> I started to write, will hopefully send something to the members list later
12:12:41 <jki> yes? do you have one more question?
12:13:28 <arisut> One question you asked in the ML, i replayed to that that I couldn't understand
12:13:43 <jki> ok, will check that again
12:13:48 <arisut> Thanks
12:14:01 <jki> then let's move on
12:14:09 <jki> #topic Kernel maintenance updates
12:14:36 <jki> [uli] "reviewing 6.1.45"
12:14:36 <masami> This week reported 2 new CVEs and 19 updated CVEs.
12:14:41 <pave1> I did reviews, 6.1.44 and renesas patches.
12:15:09 <masami> to all: thank you for answering to Dinesh-san's email.
12:15:46 <pave1> Speaking about security...
12:16:04 <pave1> I don't believe CVEs are too useful for us.
12:16:25 <pave1> Not everything security related has a CVE, and not nearly all CVEs are security problems that affects us.
12:17:15 <pave1> I wonder if we could push security team to watch CVEs, and talk to us if there's something that we really need to care about?
12:17:35 <pave1> I guess they already have to watc the CVEs for everything non-kernel...?
12:18:14 <jki> to my understanding, the security team is not yet in execution mode, rather in gap analysis and process definition mode
12:18:45 <jki> there will likely be more todos as outcomes of their analysis and assessor discussions
12:18:45 <pave1> May be true.
12:18:46 <masami> I heard from security team creating a script to watch CVEs for packages
12:19:10 <jki> ...and pull from Debian DB?
12:19:17 <jki> all that is done by Debian already
12:19:38 <jki> for their packages, not for our own ones, including the CIP kernel
12:19:44 <masami> yes. it may get CVE information from debian.
12:20:03 <pave1> But should we push the process in that direction? Security team watches for security bugs, if we have a security bug they don't like, they talk to us?
12:20:15 <masami> and cip-kernel-sec
12:20:29 <pave1> And we keep the cip-kernel-sec mostly up-to-date, so they can see our status.
12:21:12 <jki> but we need to look at patches ourselves anyway
12:21:24 <pave1> Yes, we do.
12:21:32 <jki> if some happen to relate to CVEs does not really matter
12:21:45 <pave1> But the patches we see may or may not have CVE annotation.
12:21:51 <jki> right
12:22:08 <jki> that must be clear in the process documentation that the kernel team is not CVE-driven
12:22:20 <pave1> Right.
12:22:20 <jki> CVEs are by-products
12:22:36 <jki> no difference to mainline here
12:23:13 <pave1> Reading CVEs needs special skills. I assume security team has them, and I'd like them to watch the CVE stream for "this needs fixing for CIP" bugs.
12:24:33 <jki> which should generally result in, "yes, we already know"
12:24:57 <jki> concretely: how is the situation beyond 6.1 for recent Downfalls & Co.?
12:25:12 <jki> are there / will there be backports to older kernels?
12:25:27 <pave1> Yes. But that means we don't need to go through CVE feeds and don't need to have processes for that :-).
12:26:47 <jki> ok, getting that - did we ever spot information in CVEs that weren't already in the stable patch stream?
12:27:20 <pave1> 6.1.44 has patches for "Gather Data Sampling" and they were queued for 4.14 and up.
12:28:01 <pave1> 6.1.44 has patches for "Speculative RAS Overflo\
12:28:09 <pave1> w mitigation" and they are for 5.10 and up.
12:28:49 <pave1> jki: Not really. We get the information from stable, not CVEs. Not that we are watching CVEs too closely.
12:29:10 <pave1> "Gather Data Sampling" is the Intel problem
12:29:23 <pave1> "Speculative RAS Overflow" is the AMD problem, AFAICT.
12:30:00 <jki> well, masami is reporting here every week - are you reading up details of the CVEs as well?
12:31:20 <masami> yes. if nvd or other source have vulneratiblity details I read it.
12:32:11 <pave1> I try to go through his emails, yes. (Still need to go through today's one). If something looks interesting, I sometimes do investigate, but that may happen once in two months or so.
12:32:45 <jki> then, would that time elsewhere be invested with even better efficiency?
12:32:49 <jki> and where?
12:32:58 <jki> asking openly
12:34:30 <pave1> I'm quite happy how it currently works. But I'd hate to have to specify formal rules for CVE investigation.
12:35:16 <jki> well, we have to describe how we work so that others can understand it without having to do it themselves
12:35:47 <jki> doesn't mean that we are bound to only work like that - to my understanding
12:37:29 <jki> i think this is something to discuss, not only with the security team, but they also need to present it to the assessors
12:38:36 <pave1> My preffered solution would be "security team looks at CVEs". (And we make some informal effort to "already know" if something obvious pops up).
12:39:44 <jki> then follow up on Dinesh email on that point so that also other can see and comment
12:40:06 <jki> including kernel team members on leave right now
12:40:26 <jki> ok, anything else on this topic?
12:40:49 <jki> 5
12:40:51 <jki> 4
12:40:52 <jki> 3
12:40:53 <pave1> Yep, will follow up in the email.
12:40:56 <jki> 2
12:40:58 <jki> 1
12:41:01 <jki> #topic Kernel release status
12:41:06 <jki> 4.4
12:41:25 <pave1> uli released 4.4-cip, I follwed up with 4.4-cip-rt. Should be ok.
12:41:32 <jki> 4.19
12:42:08 <pave1> 4.19-cip-rt was released, based on slightly old versions.
12:42:33 <jki> older than latest plain cip?
12:42:42 <jki> nope
12:42:57 <pave1> Not that old, but not completely fresh either.
12:43:21 <jki> yeah, a new release for base 4.19-cip should be due soon
12:43:25 <jki> ok
12:43:27 <jki> 5.10
12:43:46 <pave1> -rt is due in September, we should be ok.
12:44:06 <jki> vanilla should come soon
12:44:10 <jki> 6.1
12:44:47 <jki> looks all recent
12:45:00 <jki> ok...
12:45:03 <jki> #topic Kernel testing
12:45:03 <pave1> I'll need to check, I don't think I have suitable -rt, 6.1-rt is due soon.
12:45:20 <jki> ok, thanks
12:45:28 <jki> anything for testing today?
12:45:59 <arisut> only the isar-cip patch and discussion
12:46:03 <arisut> From me
12:46:09 <arisut> patersonc: ?
12:46:16 <jki> right, we already had that above
12:46:30 <jki> I think he is on leave
12:46:39 <arisut> Ok
12:47:03 <jki> then... moving on?
12:47:07 <jki> 5
12:47:08 <jki> 4
12:47:10 <jki> 3
12:47:11 <sietze> I realized to get some tests sent to our SQUAD staging instance
12:47:11 <jki> 2
12:47:26 <jki> ah, cool!
12:47:47 <sietze> Note sure if anybody is interested in that; this is how it currently looks like: http://squad.ciplatform.org:8000/cip-kernel/linux-cip/build/6.1.38-cip1_093191f30/
12:48:12 <sietze> We're still testing though and we still need to get https going
12:48:48 <jki> what will be the key benefits in the end when everything works?
12:49:46 <jki> single page summary? those compare features?
12:50:14 <sietze> Yes, better test overview, test results vs time, abilitiy to include other tests than kernel tests
12:50:31 <jki> ok, great
12:51:46 <jki> ok - anything else?
12:51:59 <jki> 3
12:52:01 <jki> 2
12:52:03 <jki> 1
12:52:07 <jki> #topic AOB
12:52:48 <jki> question: do you have options to host your cip releases as tarballs somewhere?
12:53:01 <jki> would that be useful beyond the CI case?
12:54:59 <jki> ok, will try to ask that also on the mailing list as follow up
12:55:13 <jki> other topic: I'm off next week, who can take over?
12:55:43 <pave1> I can take over, I guess.
12:55:52 <jki> pavel: thanks!
12:55:58 <pave1> You are welcome :-).
12:56:03 <jki> anything else for today?
12:56:58 <jki> 3
12:57:00 <jki> 2
12:57:02 <jki> 1
12:57:03 <jki> #endmeeting