13:01:46 #startmeeting CIP IRC weekly meeting 13:01:46 Meeting started Thu Jul 4 13:01:46 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:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:46 The meeting name has been set to 'cip_irc_weekly_meeting' 13:01:53 #topic AI review 13:01:58 - prepare blog entry on SLTS kernel state and challenges [Jan] 13:02:02 no news 13:02:13 and nothing else from last time 13:02:17 so... 13:02:25 5 13:02:26 4 13:02:28 3 13:02:29 2 13:02:31 1 13:02:33 #topic Kernel maintenance updates 13:02:45 i've been preparing the next 4.4 release 13:03:02 This week reported 1 new CVEs and 0 updated CVEs. It was quiet week. 13:03:10 I am reviewing 6.1.96. 13:04:29 anything else? 13:04:46 I'm reviewing .1.. 13:04:51 6.1.96. 13:06:07 There's recent -rt release, so I'll likely do matching 6.1-cip and then -cip-rt. 13:06:30 both are due these days anyway 13:08:18 ok, them moving on 13:08:21 5 13:08:24 4 13:08:24 I will releaseĀ  linux-6.1.y-cip with 6.1.96. :-) 13:08:43 perfect 13:08:48 3 13:08:50 2 13:08:52 1 13:08:57 #topic Kernel release status 13:08:57 iwamatsu> ok, thanks, that will help me. 13:09:12 all green, next to come we already discussed :) 13:09:37 almost: 5.10 and 4.19 are also due soon 13:09:52 anyway - any blockers in sight? 13:10:30 I don't see any. 13:10:39 5 13:10:41 4 13:10:42 3 13:10:44 2 13:10:46 1 13:10:48 #topic Kernel testing 13:10:57 sent issue #2594 for creating a development tool on KernelCI that can send locally changes to tests https://github.com/kernelci/kernelci-core/issues/2594 13:11:19 Siemens lab is up again 13:11:34 currently is under discussion 13:11:55 jki: nice 13:12:08 jki: Ah right, I didn't notice :D 13:12:09 Thanks 13:12:21 correction - except for the de0-nano-soc 13:12:57 we need to check that again 13:13:33 jki: Shall I delete the lab-cip-siemens-prague worker? 13:14:23 the KernelCI client could be used for testing local CIP kernel sources directly on KernelCI, with extended flexibility (like decide if publish results or which laboratory to use) 13:14:35 patersonc: we are still hoping to eventually get it online 13:14:41 just the "when" is unclear 13:14:53 arisut: That sounds useful 13:15:01 also CIP patches could be tested 13:15:06 jki: Okay, I'll leave it then - thanks 13:16:05 it should improve kernel development 13:16:08 Yes, ability to test local tree without git commit would be nice. 13:16:38 yes buildbot try already allow such feature 13:17:23 is few years that I'm talking about having something similar to what buildbot does 13:18:56 cool! 13:18:59 after many discussion I decided to just open a issue somewhere about such features 13:20:40 probably will be created as an extension of kci tool 13:22:38 anything else on testing? 13:22:47 Not from me 13:23:25 5 13:23:26 4 13:23:28 3 13:23:30 2 13:23:32 1 13:23:35 #topic AOB 13:24:00 Dinesh: you wanted to discuss about BV feedback 13:24:07 Yes 13:24:17 Shall I briefly explain? 13:24:27 jup 13:24:55 For meeting DM-3 requirement of IEC-62443-4-1 (Asessing security related issues) It expects documented process to assess security issues 13:25:15 SWG documented based on upstream https://gitlab.com/cip-project/cip-documents/-/blob/master/process/Security_issues_handling.md?ref_type=heads#dm-3-assessing-security-related-issues- 13:25:37 When we had discussion with BV, they mentioned kernel WG will be doing some assessment to select fewer security issues for CIP out of large number of issues 13:26:15 So the main point we have to discuss the criteria used to select fewer issues by kernel WG 13:26:21 Ummm. Not kernel wg. 13:27:00 one element we are starting to look into: CVE filtering based on kernel config 13:27:09 ok 13:27:48 Jan you mentioned for filtering automation in TSC 13:27:59 I mentioned that a few weeks ago, it's scheduled on our side to look into options and caveats 13:28:11 not yet there, though :) 13:28:12 ok understood 13:28:28 Or better yet. It depends on 'select from where' 13:28:46 CVEs for kernel contain too much noise to be useful. 13:29:19 yeah, this is not going to be noise cancelation 13:29:35 :) 13:29:44 We can filter based on config, and it may eliminate 50% issues, 13:29:56 but, conceptually, it could also just be applied on any interesting commit in newer kernels 13:30:02 but that's still way too much noise. 13:30:27 At least based on kernel config seems quite relevant 13:30:36 So.. someone needs to come with less noisy security issues source. 13:32:02 that's why I said in the TSC that coupling our backport procedures with what is today called "CVE" may not be helpful 13:32:57 still, the general task remains: indentify /relevant/ fixes from upstream for our kernels 13:34:27 Dinesh: anything else you'd like to discuss? 13:34:36 Yeah so as of now SWG will mark it as in-progress 13:34:46 No that's all I had for discussion 13:34:53 (Or with additional manpower. Filtering CVEs might be half-time to full-time job). 13:35:51 right, that is the risk 13:36:42 and if that should become a hard requirement for us, we need to make this transparent as early as possible 13:37:00 +1 13:37:06 Dinesh: are there any indications in that direction? 13:37:24 No hard requirement 13:37:46 good :) 13:38:29 any other business for today? 13:38:58 5 13:39:00 4 13:39:01 3 13:39:03 2 13:39:04 1 13:39:06 #endmeeting