=== athos_ is now known as athos [14:27] good morning [14:30] o/ [14:30] o/ [14:31] hey [14:31] OMW [14:31] one sec ... [14:34] now I'm hgere [14:34] too many conflicting meetings [14:34] thanks for your patience [14:34] #startmeeting Weekly Main Inclusion Requests status [14:34] Meeting started at 14:34:57 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:34] Available commands: action, commands, idea, info, link, nick [14:35] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage [14:35] #topic current component mismatches [14:35] Mission: Identify required actions and spread the load among the teams [14:35] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:35] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:35] let us see if we have anything new in there to act on [14:35] nothing new AFAICT [14:35] yep, I still ping jamespage / coreycb for jaraco every week [14:35] but indeed all in there are known cases [14:35] \o/ [14:36] \o/ [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] https://bugs.launchpad.net/ubuntu/+source/webp-pixbuf-loader/+bug/1979121 [14:36] Launchpad bug 1979121 in webp-pixbuf-loader (Ubuntu) "[MIR] webp-pixbuf-loader" [Low, New] [14:36] just this one [14:36] marked low prio and no milestone [14:36] so it might be non-urgent, but I havne't read the details [14:37] cpaelzer: re: jaraco. I think that's ready for main (?) [14:37] there's text in the bug that asks for august 25 [14:37] coreycb: jaraco.text is in, but it depends on jaraco.context which has no MIR assigned [14:37] "The package webp-pixbuf-loader is required in Ubuntu main no later than aug 25 due to feature freeze" [14:37] indeed sarnold, I set the milestone accordingly [14:37] thanks [14:38] looking for a review volunteer on webp [14:38] cpaelzer: https://bugs.launchpad.net/ubuntu/+source/jaraco.context/+bug/1975600 [14:38] Launchpad bug 1975600 in jaraco.context (Ubuntu) "[MIR] jaraco.context" [Undecided, Fix Committed] [14:38] reading coreycb ... [14:38] coreycb: it didn#t have the MIR team subscribed [14:38] fixed it [14:38] ahh ok, thanks! [14:39] now you need an AA to promote it [14:39] I can take that for tomorrow [14:39] I can have a look, but this is desktopish and it’s always a little bit off for me to ask a manual test plan (that again, we don’t have here as a wiki page :/) [14:39] cpaelzer: great, thank you [14:39] I haven't done a graphic MIR in a while I also take webpm [14:39] so having another pair of eye would be better to reenforce that this is 1. a fallback plan and 2. not optional [14:40] I will didrocks, thanks for the hint [14:40] no tests for an image loader? :( [14:41] TBH I've seen plenty of image loader tests - like convert from A->B and then check expected output [14:41] is webp non deterministic? [14:41] even non determinstic, you can add fuzzy comparison… [14:41] like could it produce slightly different output on the panel it draws to every time? [14:41] on the other hand, a package without tests can't possibly be broken.. [14:41] lol [14:41] until people are using it? :p [14:41] very helpful sarnold, very helpful :-P [14:41] * sarnold bows [14:41] anyway I'll have a look [14:42] thx cpaelzer [14:42] #topic Incomplete bugs / questions [14:42] Mission: Identify required actions and spread the load among the teams [14:42] #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:42] gsasl just landed 2.x [14:42] that is the update there [14:42] (btw, sorry for missing the parsing part) [14:42] np didrocks, we come to that later [14:43] I asked jawn-smith to have a look at the diff, not redo a whole MIR [14:43] there is always a lessons learned :-) [14:43] libiso* is also ok [14:43] was reviewed waits for the reporting team [14:43] I think we can go on [14:43] ack, will hopefully have that done today [14:43] thanks jawn-smith [14:43] #topic MIR related Security Review Queue [14:43] Mission: Check on progress, do deadlines seem doable? [14:43] #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:43] Internal link [14:43] - ensure your teams items are prioritized among each other as you'd expect [14:43] - ensure community requests do not get stomped by teams calling for favors too much [14:43] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:43] sarnold: I keep saying the list grows - but it really really does by now [14:44] you said "telegraf and something else in progress" often enough (no offense) - who do we need to bully to give you more time and people? [14:44] aye, and I don't expect any progress on it this week, the security team is sprinting this week [14:44] sarnold: can the outcome of the sprint be that this gets more attention before we have the same explosion as last cycle? [14:45] cpaelzer: I believe we do have a short meeting on MIRs to make sure we're all on the same page, yeah [14:45] ok, please push as hard as you can on it sarnold. Because we will ask you every week [14:45] I expect nothing less :D [14:45] and we includes more or less everyone requesting those cases [14:46] which ends up to be a lot of people :-) [14:46] #topic Any other business? [14:46] none here [14:46] her ewe come to the case you mentioned didrocks [14:46] Just a FYI that I rejected this from last week: https://bugs.launchpad.net/ubuntu/+source/python-charset-normalizer/+bug/1977475 [14:46] Launchpad bug 1977475 in python-charset-normalizer (Ubuntu) "[MIR] python-charset-normalizer" [Undecided, Won't Fix] [14:46] thanks slyon - we (the reporting team) agreed [14:46] I don't think it's strictly needed and would introduce duplication. ACKed by Lena [14:46] we found the switch to the normalizer, but not the debate to drop it alltogether [14:46] that really helped - thanks slyon [14:47] nothing else from my side [14:47] on gsasl didrocks and I had a talk [14:47] it was first marked as not needing a security review [14:47] nothing here I still work on the ipmitool review [14:47] and I want to point us all to the rules section [Security] for a quick check [14:47] thanks joalif [14:48] it currently says [14:48] TODO: - history of CVEs does not look concerning [14:48] TODO: - does not run a daemon as root [14:48] TODO: - does not use webkit1,2 [14:48] TODO: - does not use lib*v8 directly [14:48] TODO: - does not parse data formats [14:48] TODO: - does not open a port/socket [14:48] TODO: - does not process arbitrary web content [14:48] TODO: - does not use centralized online accounts [14:48] TODO: - does not integrate arbitrary javascript into the desktop [14:48] TODO: - does not deal with system authentication (eg, pam), etc) [14:48] TODO: - does not deal with security attestation (secure boot, tpm, signatures) [14:48] That covers a lot, but we have (didrocks now, but I myself in other cases in the past) to make a good split on when it is "parse data" [14:48] I mean is having any CLI or socket or API or I/O => "parsing data" [14:48] it's hard to say, since that's the core behaviour of nearly everything.. [14:48] I do not want to get philosphical, but [14:49] I'd propose to add one more line to catch one particular kind that obviously needs to go through security expertise [14:49] TODO: - does not deal with cryptography (en-/decryption, certificates, signing, ...) [14:49] yeah, I've been strugling with that one, too [14:49] i've always interpreted it to mean more along the lines of images, video, audio, xml, json, asn.1 .. [14:49] I was going to propose about dealing with certificates [14:49] I guess your line captures it [14:50] I like the cryptography addition, yeah [14:50] could I get an discussion7ack on that line above then we could talk about potential second rule that makes the "parsing" more granular [14:50] sounds like a good addition to me [14:50] opinions, objections, +1 on the line proposed above [14:50] +1 [14:50] +1 [14:50] +1 [14:50] +1 [14:50] also +1 on sarnold's suggestion about the parsing part [14:51] there I have come up with something [14:51] TODO: - does not parse data formats (from files [images, video, audio, xml, json, asn.1], network packets, structures, ...) [14:51] are there other commonly epxloitet attack vectors worth to be mentioned explicitly as example? [14:52] I wonder about json/yaml, because let’s say any package that embeds a json parser would be impacted, no? [14:52] (let’s say, a go app vendoring go-yaml ) [14:53] so basically, everything having configuration would end up in the security queue, is that desired? [14:53] it really does run the risk of sending *everything* through the security team.. [14:53] which would be the safest option. Then we have to deal with reality… [14:53] some additional 'from untrusted sources' might be nice, but that can be hard to tell [14:54] even libreoffice, in some way, is parsing its own file format [14:54] and ossfuzz finds things with libreoffice basically every other day.. [14:54] untrusted source is good here [14:54] yeah, I like the untrusted source as a delimiter [14:54] indeed [14:55] TODO: - does not parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source [14:55] could we vote on that as well please then? [14:55] +1 [14:55] +1 [14:55] I think mostly the 'this needs security review' vs 'this doesn't need security review' mostly works out pretty well, so in some sense I think the intuitons of the team have been pretty good [14:55] yes. and the sysadming (e.g. config files yaml/json/xml/ini) would be trusted [14:55] +1 [14:55] +1 [14:55] +1 [14:56] ok thank you all [14:56] consider both rules added (in a bit) [14:56] thank you cpaelzer! [14:56] thank you cpaelzer for the proposals :) [14:57] we can only get better if we try :-) [14:57] anything else to discuss left? [14:57] nothing from me this week [14:57] nothing from me [14:57] nothing here [14:58] ok, clsoing then [14:58] or rather "closing" [14:58] FYI: review rules in the wiki updated [14:58] (parsing error) [14:58] #endmeeting [14:58] Meeting ended at 14:58:25 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-06-21-14.34.moin.txt [14:58] thanks! [14:58] thanks cpaelzer, all :) [14:58] thanks cpaelzer, all:) [14:59] thank you! [19:01] o/ [19:03] vorlon: meeting? [19:03] I don't see the other two here. [19:19] vorlon: also, when you see this, please could you update the calendar meeting to the new phasing? I can't do that as I don't have edit rights; I think you "own" the event. [19:19] Perhaps that's why you're not here :) [19:20] hi, sorry! that's exactly right, didn't realize that's why the calendar wasn't updated [19:20] and didn't realize the meeting was on until I got email notifications of your google doc edits [19:21] updated now, for all that's worth :/ [19:21] Thanks :) [19:21] I used the time to work on the doc [19:21] ack [19:22] regarding that, are we close to a conclusion? I wasn't sure how much sil2100 had reviewed the current doc [19:22] (I'm unsurprised if he's unavailable right now fwiw, there was an... injury earlier today while he was at the vet) [19:24] It's on me at the moment. [19:24] I have to work out what we're already shipping and what exceptions might be needed. [19:25] That's the biggest task I think. [19:26] ok