14:31 #startmeeting Weekly Main Inclusion Requests status 14:31 Meeting started at 14:31:53 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:31 Available commands: action, commands, idea, info, link, nick 14:32 Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage 14:32 o/ 14:32 hello everyone, I know a few are on PTO, others are sick and I wasn't around for a few weeks so I might have lost all context 14:32 nevertheless les us get going 14:32 hi joalif 14:32 good morning 14:32 hey 14:32 hi sarnold 14:32 hi didrocks 14:32 slyon is off today 14:33 and jamespage always has a hard time to attend, btw @jamespage if you want to send anyone else representin the openstack team let us know about it 14:33 #topic current component mismatches 14:33 Mission: Identify required actions and spread the load among the teams 14:33 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:33 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:33 do I see 6 approved MIRs 14:34 - all known false positives 14:34 that might be 4 14:34 cpaelzer: an idea 14:35 libhtml-tokeparser-simple-perl and libfreezethaw-perl seem to be ready for promotion AFICS 14:35 yeah, they are 14:35 I'm taking a todo to double check and do that tomorrow morning 14:36 today is meeting overload, hence tomorrow :-) 14:36 ok, nothing else in there 14:36 feature freeze helps :-) 14:36 #topic New MIRs 14:36 Mission: ensure to assign all incoming reviews for fast processing 14:36 #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir 14:36 tund is now up 14:36 tuna already got assigned to joalif last week IIRC 14:37 I can have a look at tuned as nobody volunteered in between 14:37 sarnold: is your question of the relationship between those sufficiently answered? 14:37 I'm still reviewing it tuna has a few problems that i need to discuss 14:37 yes, didrocks that would be great 14:37 cpaelzer: not really, it'd be nice to hear something specific that it does that the others cannot do 14:37 joalif: do you want/need to discuss it here (and now)? Or with the bug reporter on the bug? 14:38 well tbh there's no template filed for tuna, should I ask for it ? (i've almost done the review) 14:38 also to run it needs root shall it go through security ? 14:39 there are some other problems but those canbe discussed with the reporter in the bug 14:39 I updated the case in regard to seths question 14:40 now reading the issue here 14:40 yes ask for a template for tuna 14:40 jsalibury just isn't away of the process details, so let him know and I'm sure he will add it 14:40 ack thanks 14:40 joalif: you mean the daemon runs as root right? 14:41 it is not a deamon, it is the application itself 14:41 it messes with cpu affinity and irqs 14:41 clearly needs a security review IMHO :) 14:41 so it needs to be run as root 14:41 yeah that's my feeling too 14:41 it needs security check 14:42 I guess we are all clear why that rule exists, running as root ives it more power which makes it more prone to mess up things when exploited 14:42 hence yes, it usually means that we want a security check 14:42 however this is for later, there are other need to be done before security review 14:42 even though, not being a daemon there will not be a port or api that can be accessed and exploited 14:43 there might be e.g. users dropping conffiles somewhere for root to pick it up via the tool - and boom 14:43 somewhere in the service there's a d-bus interface 14:43 is it, then eeven more -> yes security review 14:43 that might be more the tuned thing than a tuna thing 14:43 sarnold: i think dbus is for tuned 14:43 and joalif, if you have more for them to answer or implement reflect it back to them and set it to incomplete 14:43 since we also wait for the answers to Seths question 14:43 yup I'll do 14:43 and to whatever didrocks finds on tuna 14:43 I guess for now this case is ok 14:43 yep 14:43 it won't be 22.10 material anyway 14:44 nothin else in the list 14:44 #topic Incomplete bugs / questions 14:44 Mission: Identify required actions and spread the load among the teams 14:44 #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir 14:44 openconnect is stil getting updates, but also still incomplewte 14:44 no need to act on it 14:45 qtr I got contacted by seb 14:45 ah, good 14:45 he mentioned that he discussed it her ein the past, we entered a mail series that tries to come up with "if we do, what would we need to ack it as special case" 14:45 after some iterations of that we might come back here for a group ack 14:46 but it isn't ready enough yet 14:46 so I can#t discuss more details yet, but will come back 14:46 teasing :) 14:46 lol 14:47 TL;DR in some cases e.g. vendoring and some other cases e.g. multipath/kernel not having all HW - we already make excuses. But we then in turn rquire a clear "yes I really know what I'm committing to here" + "This is how I try to make this situation better in the long run" 14:47 something along these lines it might end up to make me consider it a "well ok, special case ack" 14:48 I understand the case and want to help, but OTOH I do not want to make it too easy tough, or it will just become the pattern everone uses 14:48 ok enough of that, going on ... 14:48 #topic MIR related Security Review Queue 14:48 Mission: Check on progress, do deadlines seem doable? 14:48 #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir 14:48 Internal link 14:48 - ensure your teams items are prioritized among each other as you'd expect 14:48 - ensure community requests do not get stomped by teams calling for favors too much 14:48 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 14:50 unfortunately I stillh aven't caught up after covid :/ mdevctl is in progress, mark is working on editorconfig-core -- I'm worried that it might allow untrusted inputs straight to pcre, which is historically a horrible idea 14:50 but pcre itself it mean to be "safe" as it is in main- isn't it? 14:50 the team has other, higher, priorities at the moment, so it'll be just me again for a while 14:50 not really :( 14:51 the expression compiler is unsafe 14:51 it was so great seing the recent progress, sad to hear you are along again 14:51 but I understand that there are many things pulling, and for now we are way into FF anyway 14:51 afaik only go and rust's regex engines are intended to be safe for untrusted inputs 14:51 sarnold: if there is anything not "yes ok" on mdevctl please let myself and athos know immediately about it 14:51 (they're not perfect but at least they try) 14:52 cpaelzer: will do, athos has been very responsive so far :) 100% would recommend, hehe 14:52 great 14:52 sarnold: one more thing - all the ccid/opensc/smart-card which is marked "in progress" 14:53 sarnold: I was told this might get a bump as you lost some related resources, does this go back to square #1 or will this stay in this state? 14:53 cpaelzer: good question. I think it'd be wise for security to talk again with desktop and make sure it's still a desired feature 14:53 sarnold: btw, gnome-text-editor 42 embeds editorconfig-core; 43 is switching to use the system library 🫤 14:53 I think it is for all the enterprise desktop people asking for it 14:53 cpaelzer: maybe there's sufficient interest to keep trying on it once we've made more hires 14:54 jbicha: ugh :) 14:54 but yeah having that talk is the right next step sarnold 14:54 jbicha: thanks for fighting the devendoring fight :) 14:54 jbicha: so we had it all the time, just now it becomes visible? 14:54 cpaelzer: gnome-text-editor is new to main for 22.10 14:54 I see 14:54 well, gnome-text-editor is pretty new, replacing whatever the old gnome text editor was, right? 14:54 I didn't devendor it; upstream did to get us to pcre2 I guess 14:55 ok, but mark is ont hat csae 14:55 so we can expect some progress 14:55 goo 14:55 * athos feels recommended! 14:55 I think we are fine with this section 14:55 :) 14:55 athos: - you are 14:55 #topic Any other business? 14:55 yes 14:56 nothing from me, the one I had was that libqtr thing I mentioned above 14:56 didrocks: joalif: anything from you 14:56 nothing from me 14:56 sarnold: what is it then? 14:56 nothing for me 14:56 the openconnect, stoken, fstrm, etc MIRs were all filed by Luís -- and he has been uninvited from ubuntu for another year 14:56 s/another// 14:56 "uninvited" ?! 14:57 yeah, the community council heard enough complaints about his working style that they weren't able to address to their satisfaction 14:57 I hope when the year is up he's more open to workflow suggestions.. 14:57 I see 14:58 so you are saying there will be a social/community aspect to the review7approval of these once they are no more "incomplete" 14:58 anyway, we've got a half-dozen or so half-filed MIRs in various states; we could either continue on without his input, or set them all WONTFIX, or leave them as is and let them expire on their own organically 14:59 he signed up teams for support of the things without actually having conversations with the affected teams, so I don't think we can just take the bugs at face value 14:59 I would not want to stop someone trying to improve Ubuntu. But one of the main things all these need is a team that will own it, we might check on that and only that first when the cases are no more incomplete. 14:59 desktop hasn't reviewed the openconnect request. I was concerned that Security was hesitant about it in their initial review 14:59 without finding such, we can't go on - no matter how ok or not any other aspect is 15:00 sarnold: we might just point at the "owning team rule" in FYI updates to the cases 15:00 just to manage expectations 15:00 fells better (to me) than immediately going to Won't Fix 15:00 WDYT? 15:00 yeah, basically the fact that the team owner should agree first is the deal breaker 15:00 these bugs weren't a significant hindrence to our meeting today so status quo might be perfectly fine 15:01 ok 15:01 thanks for raising this for awareness 15:02 will help to not spend too much effort before those details are clarified 15:02 that seems it was all we had 15:02 ready to close this for today? 15:02 fine by me 15:02 sounds good! 15:02 thanks cpaelzer, all :) 15:02 thanks cpaelzer, all :) 15:02 ok, thank you all! 15:02 thanks cpaelzer, all 15:02 #endmeeting