[14:27] slowly prepping the MIR meeting [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:39] 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 [15:02] Meeting ended at 15:02:52 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-09-06-14.31.moin.txt === genii_ is now known as genii === arraybolt3_ is now known as arraybolt3