14:32 <cpaelzer> #startmeeting Weekly Main Inclusion Requests status 14:32 <meetingology> Meeting started at 14:32:54 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:32 <meetingology> Available commands: action, commands, idea, info, link, nick 14:32 <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) 14:33 <cpaelzer> last week we expected this one might be quick (so late in the cycle) and we use the time to discuss the blob case in wwan unlock 14:33 <cpaelzer> let us see if the assumption holds true 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> yep, easy as intended 14:33 <sarnold> good morning 14:34 <cpaelzer> #topic New MIRs 14:34 <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing 14:34 <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:34 <cpaelzer> none 14:34 <cpaelzer> #topic Incomplete bugs / questions 14:34 <cpaelzer> Mission: Identify required actions and spread the load among the teams 14:34 <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:35 <cpaelzer> nothing super new, and the expected https://bugs.launchpad.net/ubuntu/+source/lenovo-wwan-unlock/+bug/2058192 we will try to talk about later 14:35 <cpaelzer> #topic Process/Documentation improvements 14:35 <cpaelzer> Mission: Review pending process/documentation pull-requests or issues 14:35 <cpaelzer> #link https://github.com/canonical/ubuntu-mir/pulls 14:35 <cpaelzer> #link https://github.com/canonical/ubuntu-mir/issues 14:35 <slyon> I worked on https://github.com/canonical/ubuntu-mir/pull/66 today, which should be ready for merging now 14:35 <cpaelzer> rust is old and on slyon who provided https://github.com/canonical/ubuntu-mir/pull/66 14:36 <cpaelzer> yeah - the same :-) 14:36 <cpaelzer> I only had a glance, but enough others - especially the rust folks said yes 14:36 <cpaelzer> so I'm happy to merge if no one wants to stop me 14:37 <slyon> I'm now recommending the approach used in s390-tools, using a .orig-rust-vendor.tar.xz tarball for vendored crates 14:37 <slyon> providing an example for automation via debian/rules 14:37 <cpaelzer> only if upstream is providing that? 14:37 <slyon> unrelated to upstream. 14:37 <cpaelzer> or also otherwise us creating it in a DFSG repackage kind of step? 14:38 <slyon> yes 14:38 <cpaelzer> ok with me 14:38 <slyon> is mostly us creating it, because upstream/debian doesn't rely too much on vendoring 14:38 <cpaelzer> Since you had a closer look slyon, did anyone bring up that the ecosystem is maybe more mature and we should change to no-vendoring or at least reduced-vendoring? 14:39 <slyon> No news on this, yet. 14:39 <cpaelzer> thanks 14:39 <slyon> I'll try to catch a few Toolchain people at the next sprint (again) to discuss this topic 14:39 <cpaelzer> ok, I've read through and will merge - we can further improve from here but this is (much) better than what we have - hence a merge is ok 14:39 <sarnold> given the way versions of crates get locked together, I'd be surprised if that goal is closer than it was before 14:40 <cpaelzer> sarnold: me too, but it is worth rechecking such assumptions of the past 14:40 <doko> o/ 14:40 <cpaelzer> hi doko 14:40 <sarnold> heya doko 14:40 <cpaelzer> merged and thereby bug closed 14:40 <cpaelzer> #topic MIR related Security Review Queue 14:40 <slyon> thx! 14:40 <cpaelzer> Mission: Check on progress, do deadlines seem doable? 14:40 <cpaelzer> Some clients can only work with one, some with the other escaping - the URLs point to the same place. 14:41 <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:41 <cpaelzer> #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:41 <cpaelzer> Internal link 14:41 <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect 14:41 <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much 14:41 <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 14:41 <sarnold> I don't believe anything currently in flight or yet to start will have any progress this week 14:42 <cpaelzer> sarnold: do you happen to know if any still-in-progress are needed for oracular which is extra-soon ? 14:42 <sarnold> the mad dash to finish roadmap items has consumed everything in its path 14:42 <sarnold> I can't speak to the consequences for our colleagues for these few stragglers :( 14:43 <cpaelzer> If in doubt, those responsibilities (like these MIR reviews) need to be "in the roadmap" to avoid them getting blown out by such a rush 14:43 <cpaelzer> Maybe an improvement in planning time allocation to suggest? 14:43 <cpaelzer> But nothing to debate now and here 14:43 <cpaelzer> #topic Any other business? 14:44 <sarnold> lenovo wwan thingy 14:44 <doko> I wanted to propose a in-person meeting during the engineering sprint, like some "MIR office hours", with the first half of the meeting with just the MIR team members, followed by the second half where everybody can join and have questions/suggestions. Would that be ok with you? 14:45 <slyon> +1 for a in-person MIR meeting at the sprint 14:46 <sarnold> yes, good idea 14:46 <cpaelzer> doko: it was always worthwhile to do, but the calendar keeps filling up ... 14:46 <cpaelzer> let me have a look 14:46 <doko> I assume you have scheduling powers, so just find a slot ... 14:46 <cpaelzer> I have all power :-) 14:50 <cpaelzer> found and sent 14:51 <cpaelzer> Monday after lunch 14:51 <cpaelzer> ok, not much time 14:51 <cpaelzer> let me set the stage 14:51 <doko> ta 14:51 <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/lenovo-wwan-unlock/+bug/2058192 14:51 <cpaelzer> The question there is mostly "uncertainty" 14:51 <cpaelzer> we rarely have something that wants to go to restricted in the first place 14:51 <cpaelzer> so none of us has a lot of "that is how we usually do" feeling 14:52 <cpaelzer> Furthermore I've heard many including myself get more and more troubled with such blob cases (had similar with keys) like "How would later one check on an SRU if the change is good/bad/fake" 14:52 <cpaelzer> We are asking us the same questions but for introducing it 14:53 <cpaelzer> I think restricted exists for just that, the neccessity of reality sometimes forcing us to things like that :-/ 14:53 <cpaelzer> But still I understand that we all feel not to ok with it 14:54 <cpaelzer> But I think we need to look at the pure process, what of the requests in https://bugs.launchpad.net/ubuntu/+source/lenovo-wwan-unlock/+bug/2058192/comments/5 are done or still open 14:54 <cpaelzer> sarnold: can you explain what exactly this is about https://bugs.launchpad.net/ubuntu/+source/lenovo-wwan-unlock/+bug/2058192/comments/8 ? 14:55 <cpaelzer> to have it follow https://github.com/canonical/ubuntu-mir/blob/main/exceptions/OEM.md ? 14:56 <sarnold> cpaelzer: we were mostly interested in trying to keep these blobs off unrelated computers 14:56 <cpaelzer> ok, discussion moved on - it shall be in the normal archive (comments ~13-end 14:56 <sarnold> cpaelzer: very few ubuntu users have the oem archives configured in their apt sources 14:56 <slyon> lenovo-fccunlock is still shipping a /usr/lib/libmodemauth.so without corresponding .symbols file.. 14:56 <sarnold> cpaelzer: so our thought was putting it in the oem archive might do a better job of restricting it to only people who would benefit 14:56 <slyon> I guess that is what didrocks mention in his first required TODO 14:57 <cpaelzer> thanks sarnold, but the discussion evovled to ask to target the archive and in there restricted again - right? 14:57 <cpaelzer> slyon: I agree - to me it seems this is mostly about checking the needs raised in https://bugs.launchpad.net/ubuntu/+source/lenovo-wwan-unlock/+bug/2058192/comments/5 if they are now complete or now 14:58 <cpaelzer> doing that we will know more clearly what is still open 14:58 <cpaelzer> and then there is security 14:58 <slyon> ACK. IMO some of them got addressed, but not all 14:58 <cpaelzer> Review was held back when it was considered to go to OEM, but since it is back a review is again needed 14:58 <cpaelzer> but then, what do you review in a blob? 14:58 <slyon> maybe it'd be best for didrocks to take a 2nd look. reconsidering if his requests were resolved? 14:58 <cpaelzer> ack slyon, maybe we could ask didrocks to do the official check of his asks what is done and what isn't? 14:58 <slyon> we don't review the blob... that's why we put it into "restricted". 14:59 <cpaelzer> didrocks: ? (I know you are budy, but please pick that up later if you can) 14:59 <cpaelzer> yeah, but in that case is it just "no security review" or would you still do one for where you can sarnold? 14:59 <sarnold> cpaelzer: yes, the conversation did move, when they were worried that the smaller user base would mean too many users who need it can't get it 14:59 <slyon> still we can make sure the packaging is clean, potentially has tests and proper confinement 14:59 <cpaelzer> slyon: double +1 15:00 <slyon> confinement might be even more important here, considering this is a blob 15:00 <cpaelzer> agreeing a lot 15:00 <cpaelzer> but ok for the scope of this meeting, back for a check by didrocks what was fulfilled and then back to security to do what "can be done" 15:00 <cpaelzer> is that ok as an outcome for now 15:02 <cpaelzer> time is up, I consider silence a weak ok for now 15:02 <cpaelzer> thanks for having that discussion to get myself and many others to the same level 15:02 <slyon> this is not nice, btw: https://git.launchpad.net/ubuntu/+source/lenovo-wwan-unlock/tree/debian/lenovo-fccunlock.service "User=root" and executing a random binarry blob.. 15:03 <sarnold> I'm not surprised that the driver requires privileges to change something as fundamental as allowed radio frequency ranges 15:03 <cpaelzer> indeed sarnold, but that just asks for e.g. apparmor 15:04 <cpaelzer> it can have root, but should be limited to do just what and where it is supposed to 15:04 <sarnold> *nod* I wish it had asked for systemd's seccomp filter lists, too 15:04 * didrocks is back…logging 15:04 <cpaelzer> when introducing the "encourage isolation" rules that the level of enforcement depends on the case 15:04 <slyon> sarnold: ack 15:04 <cpaelzer> this is a case which is indicating rather strong enforcement to make those required 15:05 <cpaelzer> other cases can be weaker and that is fine, but here it is important and we seem to agree on that 15:05 <cpaelzer> let me try to conclude the meeting then, as some are already distracted 15:05 <cpaelzer> thank you for the discussion 15:05 <didrocks> makes sense to me. I’ll have a second look at it and see where we stand. I still think even if the blob is binary that we should get the packaging to a certain level 15:05 <cpaelzer> thanks didrocks 15:05 <slyon> thanks! 15:05 <cpaelzer> yes, packaging at minimal level and isolation kind of mandatory in this case 15:06 <cpaelzer> #endmeeting