=== JanC is now known as Guest1579 === JanC_ is now known as JanC === JanC_ is now known as JanC [14:30] o/ [14:30] o/ [14:30] o/ [14:30] o/ [14:30] o/ [14:30] hi [14:31] #startmeeting Weekly Main Inclusion Requests status [14:31] Meeting started at 14:31:05 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:31] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) [14:31] plenty of people said hi already before the meeting got started [14:31] so let me get going with the agenda [14:31] #topic current component mismatches [14:31] Mission: Identify required actions and spread the load among the teams [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:31] good morning [14:31] rust -> fonts [14:32] we know rust is temporarily demoted [14:32] not suer why the fonts would show up now [14:32] but given how things were int he past probably a false positive [14:32] cpaelzer: font's are only from the -doc packages, can be ignored [14:32] ack [14:32] they will stay in universe [14:32] then for actual fonts [14:32] probably a previous mix of main vs universe binaries has been turned into "omg all these universe packages should be in main" [14:32] fonts-liberation -> fonts-liberation-sans-narrow [14:33] the former is a desktop package [14:33] AFAIK those get a relative easy pass [14:33] if they are really just fonts [14:33] and there is no active code [14:33] but we'd still want to see a bug that states that it is intentional and wanted [14:33] because no matter how simple, the package will need an owner [14:34] that was exactly my point [14:34] didrocks: can you carry that to the desktop folks? [14:34] sure, will do [14:34] I feel like parrot [14:34] the MIRs for the perl explosion will come [14:34] soon (tm) [14:35] jaraco seems almost ready right? [14:36] ok joalif reviewed the last element recently [14:36] todo is back on openstack [14:36] there are some open TODOs from joalif [14:36] jamespage: ^^ FYI [14:36] yep [14:36] so far that is all I see in mismatches [14:36] no further things that we need to act on in there right now [14:37] #topic New MIRs [14:37] Mission: ensure to assign all incoming reviews for fast processing [14:37] #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:37] empty [14:37] wow [14:37] broken? [14:37] xD [14:37] lol [14:37] * sarnold pokes launchpad with a stick [14:37] zen attitude :p [14:37] o/ [14:37] don’t be as negative as sarnold :p [14:37] #topic Incomplete bugs / questions [14:37] Mission: Identify required actions and spread the load among the teams [14:37] #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:38] 5 incompletes with recent updates [14:38] dhcpd I fixed the state as it has a few open todos left [14:38] didrocks: did the same for aom [14:39] libhttp-cookiejar-perl seems to be worked on by foundations [14:39] python-rlpycairo and all reverse dependencies only used by hplip should be demoted it seems… [14:39] bug #2026608 I don't think this necessarily needs a security-review (considering lua has been in main for a while and covered by our security team), but maybe sarnold still wants to do a spot check and see if a full review would be useful (assign ubuntu-security, if you feel like) [14:39] -ubottu:#ubuntu-meeting- Bug 2026608 in lua5.4 (Ubuntu) "[MIR] lua5.4" [Undecided, Incomplete] https://launchpad.net/bugs/2026608 [14:39] didrocks: right. I brought that up with the desktop team, looks like we can demote hplip + dependencies later this cycle [14:40] ok, good on hplip+dependencies then [14:40] slyon: I agree on 2026608 [14:40] slyon: ack, thanks [14:40] sarnold: what do you think? [14:41] I'm inclined to agree that it just needs a very quick once-over [14:41] on the quality side I agree to slyons list [14:41] we need to give it some love [14:41] to make it better than it is [14:41] Lena will ping back on the case once ready [14:41] nothing for us to act now [14:42] ok, next topic then [14:42] #topic Process/Documentation improvements [14:42] Mission: Review pending process/documentation pull-requests or issues [14:42] #link https://github.com/canonical/ubuntu-mir/pulls [14:42] #link https://github.com/canonical/ubuntu-mir/issues [14:42] 31 and 17 wait [14:42] blocked by other things [14:42] but 33 and 32 I'd land if there are no objections [14:43] thanks dviererbe btw for the quick reviews [14:43] thoughts/complaints on https://github.com/canonical/ubuntu-mir/pull/32 or https://github.com/canonical/ubuntu-mir/pull/33 ? [14:43] -ubottu:#ubuntu-meeting- Pull 32 in canonical/ubuntu-mir "Clarify endpoint rules" [Open] [14:43] -ubottu:#ubuntu-meeting- Pull 33 in canonical/ubuntu-mir "Guide how to check nobody/suid rules" [Open] [14:44] * slyon approved on GH [14:44] the find calls needs to be on the built binary, no? Otherwise dh_fixperms will fix them if nothing special in debian/rules? [14:44] (so unsure about those checks, I generally only rely on grepping) [14:45] yeah, there might be more like postinst [14:45] that is why my added line says "at least" [14:45] I felt that people might check even less than the find and grep [14:45] so wanted to provide a hint [14:45] if you find suid set then one can have a look at fixperms and others [14:46] right, my point is that find on the source package will not give you what you expect :) [14:46] like the built binaries [14:46] yeah [14:46] TBH I expected to check both src and extracted debs or so [14:46] and another question on the other on the other PR: why checking dbus in particular? (it’s all local) [14:46] comments added to both [14:46] we can say the same then on any unix socket? [14:46] the case I looked at had dbus and that is just as much an "open port" of some sort [14:47] since I didn't want to extend the list infinitely I added "dbus or similar" [14:47] IHO, but I'm happy to discuss, any kind of listning turn into potential attack vectors right? [14:47] +M [14:48] hum, I kind of disagree for things that are listening "locally", in that sense, clients connecting to the system bus are even more harmful and don’t enter this list [14:48] let’s iterate over the PRs [14:48] ok then [14:48] pstpone for the meeting [14:48] throw the comments onto the PRs [14:48] some of you already did [14:48] > I felt that people might check even less than the find and grep [14:48] Just a thought: Would that be a good idea to create a tool like check-mir that makes it easier for people to check for sid/gid if so many do it worng or don't do it at all? [14:48] I'll rework them and we can talk again here next time [14:49] dviererbe: I found that often people then run the tool, do not know what/why it does, and then do fail to think e.g. about the new similar thing [14:49] dviererbe: heh, yeah, I immediately wondered why we don't have an easy tool to find all the setuid/setgid files/directories in the packages [14:49] you can write and maintain one :-) [14:49] all the PR tries is to help with suggestions [14:50] that's my fear [14:50] I'm ok for now [14:50] have enough on those to work on them [14:50] going on in the agenda [14:50] #topic MIR related Security Review Queue [14:50] Mission: Check on progress, do deadlines seem doable? [14:50] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [14:50] #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:50] #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir [14:50] Internal link [14:50] - ensure your teams items are prioritized among each other as you'd expect [14:50] - ensure community requests do not get stomped by teams calling for favors too much [14:50] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:51] I believe we are set. Big item is cargo being assigned to a reviewer [14:52] yeah [14:52] that's great to hear! [14:52] dotnet is also bug [14:52] big [14:52] that does not have a face on it yet right? [14:52] correct [14:53] nvme-stast just entered the queue as I completed review this morning [14:53] i'm worried that the "transition away from the dead package" story isn't quite complete yet [14:53] also looking for a reviewer [14:53] sarnold: well, we can wait for more details on this - but it would not block the security reivew would it? [14:53] cpaelzer: no, but it is also probably more important than the security review [14:54] it is required TODO #1 to clarify that further [14:54] and I understand the discussion is underway [14:55] Unless that is completed and approved as being sufficient it won't be promoted [14:55] sounds good to me [14:55] but to not lose too much time I think foundations would appreciate to enter the assigned security review queue [14:55] I think we are ok on that, give it a thought if it could be assigned [14:55] going on [14:55] #topic Any other business? [14:55] nothing here [14:55] nothing either [14:55] nothing from me [14:56] just fyi, i wont be joining the next 4 mtgs [14:56] o/ :-) [14:56] bank holidays + pto [14:56] joalif: nice :) [14:56] heya seb128 [14:56] quick one, the fonts-liberation-sans-narrow mentioned earlier [14:56] impressive joalif :-) [14:56] it seems to be a rename from fonts-liberation [14:56] oh yes, iirc next week is a midcycle sprint, are we intending to have this meeting next week? [14:56] basically Debian did [14:57] fonts-liberation2 -> fonts-liberation [14:57] and [14:57] on time off, there will be a sprint this (not much impact) and next (more impact) week that keeps people busy [14:57] fonts-liberation -> fonts-liberation-sans-narrow [14:57] I'd appreciate, due to the sprint, someone taking over for me next week [14:57] because that's the only font remaining provided by the old srcname [14:57] do we still need a MIR? [14:57] (same, I will be in the sprint, so if someone else is free to take over…) [14:57] cpaelzer: I can probably run the meeting next week. [14:58] seb128: file a bug and explain, so there is an audit trail. Does not need to be a full MIR template [14:58] cpaelzer, ack, thanks [14:58] thanks slyon [14:58] ok then, seems we are done for today [14:58] thanks cpaelzer, all [14:58] thanks cpaelzer, all :) [14:58] thanks, all [14:58] thanks cpaelzer, all! [14:58] joalif: we will keep the best cases open for when you are back then :-P [14:58] #endmeeting [14:58] Meeting ended at 14:58:51 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-07-18-14.31.moin.txt [14:58] thanks all o/ [14:58] LOL [14:59] thanks cpaelzer ;) [14:59] joalif: all the perl stuff! :p [14:59] thanks! [15:03] thanks! [15:08] and as a follow up FYI, https://bugs.launchpad.net/ubuntu/+source/fonts-liberation-sans-narrow/+bug/2028070 [15:08] -ubottu:#ubuntu-meeting- Launchpad bug 2028070 in fonts-liberation-sans-narrow (Ubuntu) "[MIR] fonts-liberation-sans-narrow" [Undecided, New] === JanC_ is now known as JanC