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