| mdeslaur | \o | 19:59 |
|---|---|---|
| * slangasek waves | 19:59 | |
| slangasek | I think we have some topics this week | 19:59 |
| slangasek | hopefully we also have a chair | 20:00 |
| mdeslaur | hi infinity! | 20:00 |
| * slangasek waves | 20:00 | |
| infinity | Oh look, I'm the chair. | 20:00 |
| infinity | #startmeeting Ubuntu Technical Board | 20:01 |
| meetingology | Meeting started Tue Feb 27 20:01:21 2018 UTC. The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology. | 20:01 |
| meetingology | Available commands: action commands idea info link nick | 20:01 |
| infinity | So, who's here? Do we have quorum? | 20:01 |
| * stgraber waves | 20:02 | |
| infinity | We do! | 20:02 |
| mdeslaur | wow! hi stgraber! | 20:02 |
| infinity | #topic Action Review | 20:02 |
| infinity | MaaS thingee: I've still entirely failed to review the current state. I should make a personal TODO item to get that done. | 20:03 |
| infinity | support-status thingee: Superseded by recent SRUs. | 20:03 |
| infinity | slangasek: Bugs thingee? | 20:03 |
| slangasek | infinity: continues to be backlogged | 20:03 |
| infinity | Budgie LTS status, that seems to have been handled on-list, unless we want a quorum vote taken? | 20:04 |
| mdeslaur | nah | 20:05 |
| infinity | I'm +1 to mdeslaur and stgraber's cumulative +2 | 20:05 |
| slangasek | I had also +1'ed it, mind | 20:05 |
| slangasek | I think we're good | 20:05 |
| infinity | Kay. | 20:05 |
| infinity | That brings up another topic, which is that we should probably send out a call for LTSiness and renew all the flavours. | 20:06 |
| slangasek | under TB or Release Team hat? | 20:06 |
| infinity | Yes. | 20:06 |
| tsimonq2 | Did I hear "flavor"? :) | 20:07 |
| slangasek | is that an [action] for you? :) | 20:07 |
| infinity | TB needs to approve them, but if we're okay with the status quo, then just release team. | 20:07 |
| infinity | The one that I'm currently not okay with is kylin at 5y, since that used to be based on them being based on Ubuntu, which they aren't anymore. | 20:07 |
| infinity | I think they're not Xubuntu based? | 20:07 |
| infinity | IIRC. | 20:07 |
| infinity | s/not/now/ | 20:07 |
| tsimonq2 | (Ubuntu MATE) | 20:08 |
| tsimonq2 | UKUI is a fork of MATE | 20:08 |
| infinity | Ahh, or that. | 20:08 |
| infinity | Either way, they're now based on a 3y flavour, and unless they really think they can handle the extra 2y on their own (which I'd strongly discourage), we should drop them to 3y. | 20:09 |
| slangasek | full ack | 20:09 |
| slangasek | infinity: where are you seeing this as 5y, btw? | 20:09 |
| infinity | slangasek: maintenance-check.py in lp:ubuntu-archive-publishing | 20:10 |
| infinity | DISTRO_NAMES = [ | 20:10 |
| infinity | "ubuntu", | 20:10 |
| infinity | "ubuntukylin", | 20:10 |
| infinity | ] | 20:10 |
| infinity | DISTRO_NAMES_SHORT = [ | 20:10 |
| infinity | "kubuntu", | 20:10 |
| infinity | "lubuntu", | 20:10 |
| infinity | "ubuntu-budgie", | 20:10 |
| infinity | "ubuntu-mate", | 20:10 |
| infinity | "ubuntustudio", | 20:10 |
| infinity | "xubuntu", | 20:10 |
| infinity | ] | 20:10 |
| infinity | So, kylin should move to short for Bionic, and Budgie needs to be added. | 20:10 |
| infinity | And we need to get everyone to confirm the current status. | 20:10 |
| slangasek | budge is there | 20:10 |
| slangasek | i | 20:11 |
| infinity | So it is. | 20:11 |
| tsimonq2 | One thing; if Lubuntu Next 18.04 should be regarded as a 9m rather than a 3y, is there anything that needs to be done on the release team or TB end? | 20:12 |
| infinity | I think I'll JFDI the kylin move, then do the confirmation thing. | 20:12 |
| slangasek | infinity: +1 | 20:12 |
| slangasek | infinity: seems you already declared Budgie LTS in October, according to the commit history ;) | 20:12 |
| infinity | tsimonq2: lubuntu-next has its own seeds, right? | 20:12 |
| infinity | Or is it in the lubuntu seed set? | 20:12 |
| tsimonq2 | infinity: Correct, but it's under the same branch as the other Lubuntu ones. | 20:12 |
| tsimonq2 | Right. | 20:12 |
| slangasek | tsimonq2: do you intend lubuntu-next to release, this time? Given that it's been daily-only in the past | 20:12 |
| tsimonq2 | Correct, that's the goal. | 20:13 |
| tsimonq2 | So the *-share-* and the *-gtk-* seeds under the Lubuntu branch should be 3y as normal, and *-qt-* should be 9m. | 20:14 |
| infinity | Yeah, that'll take a little bit of mangling of maintenance-check. | 20:14 |
| tsimonq2 | But is the TB OK with that plan? | 20:15 |
| infinity | I'm honestly not sure I see the point in you releasing it as kinda-supported before you switch it over to being the new hotness. | 20:16 |
| slangasek | do we have precedent for a flavor releasing a "next" image as a release image? | 20:16 |
| slangasek | I'm trying to recall what Kubuntu did with plasma | 20:16 |
| infinity | No. | 20:16 |
| * slangasek nods | 20:16 | |
| infinity | active and plasma never got released officially until the switch. | 20:16 |
| slangasek | so I'd say there's some healthy skepticism about this plan | 20:16 |
| slangasek | maybe tsimonq2 should propose it on the mailing list and we should discuss it further? | 20:17 |
| tsimonq2 | slangasek: The TB mailing list or the Release Team one? | 20:17 |
| infinity | That said, regardless of the plan, maint-check will need a bit of a mangle because you're building both from the same seed set, unlike kubuntu that used another. | 20:17 |
| slangasek | tsimonq2: TB, I think | 20:17 |
| tsimonq2 | infinity: If this is approved by the TB, I'll volunteer to take that on. | 20:18 |
| tsimonq2 | slangasek: Sure, I can do that by the next TB meeting. | 20:18 |
| slangasek | yeah, I was going to say, it'd be great to have tsimonq2 submit the patch for maint-check :) | 20:18 |
| infinity | It's not a hard mangle, per se. Just needs a filter on the SUPPORTED=all bit. | 20:18 |
| tsimonq2 | Right, I can take care of that. :) | 20:19 |
| infinity | You'll want supported=(all-next) and then supported-not-much=next | 20:19 |
| infinity | And not-much.length=9m | 20:19 |
| infinity | All pseudocode, obviously. | 20:19 |
| tsimonq2 | Sure, and I can look into it more myself. | 20:20 |
| tsimonq2 | Thanks. | 20:20 |
| infinity | #action tsimonq2 to bring up the support/release status of lubuntu-next on the TB list, and then submit patches to maintenance-check according to the final plan | 20:20 |
| meetingology | ACTION: tsimonq2 to bring up the support/release status of lubuntu-next on the TB list, and then submit patches to maintenance-check according to the final plan | 20:20 |
| infinity | #topic Ubuntu MATE Software Boutique | 20:21 |
| flexiondotorg | o/ | 20:21 |
| infinity | flexiondotorg: Oh hai. | 20:21 |
| slangasek | hello! | 20:21 |
| infinity | slangasek: You want to drive this bit? | 20:21 |
| infinity | Because context. | 20:22 |
| slangasek | well, I think I've mostly laid out my concerns on the mailing list | 20:22 |
| slangasek | infinity, mdeslaur, stgraber: did you have a chance already to read that thread? | 20:22 |
| slangasek | I can summarize, regardless | 20:22 |
| infinity | I'm reading now. But a summary would be nice. | 20:22 |
| stgraber | I've read the thread pretty quickly as they came in | 20:23 |
| slangasek | Ubuntu MATE Software Boutique allows push-button installation of packages from a variety of sources | 20:23 |
| slangasek | including ppas, and third-party sources | 20:23 |
| slangasek | some of which are configured by downloading the gpg keys over plaintext http | 20:23 |
| slangasek | and none of these details are surfaced to the user when they choose this software for installation | 20:24 |
| slangasek | so the concern is that this does not align with the TB-approved archive policy https://wiki.ubuntu.com/ExtensionRepositoryPolicy | 20:24 |
| mdeslaur | third-party sources? | 20:24 |
| slangasek | mdeslaur: I'd have to dig into the code for details; but it includes obvious ones like the upstream Google Chrome repository, and some less obvious ones for repos somewhere in India | 20:25 |
| mdeslaur | ooh :( | 20:26 |
| flexiondotorg | Those packages that Boutique installs from 3rd parties are always the official apt repos of the vendor. | 20:26 |
| slangasek | like, something called 'enpass' which is a 'cross-platform, complete password management solution [...]'; can't think of any reason anyone might have concerns about the gpg key used to authenticate /that/ repo being downloaded from http://repo.sinew.in/keys/enpass-linux.key | 20:26 |
| slangasek | flexiondotorg: yes, and we do not have cryptographic trust to any of those upstream repos | 20:27 |
| infinity | Yeah, so, there are multiple concerns here for sure. | 20:27 |
| mdeslaur | and we can't update them or revoke them if they are compromised, etc. | 20:27 |
| infinity | The first is that the user doesn't appear to be reasonably informed. | 20:27 |
| slangasek | so that's my summary of the current state | 20:27 |
| slangasek | flexiondotorg: anything else that I've missed? | 20:27 |
| infinity | The second is that those keys should be shipped in the package, not downloaded on demand. So there's at least some claim that the developer of the package has vetted the key is the right one. | 20:28 |
| flexiondotorg | The source of the packages is available from the Details along side each package. | 20:28 |
| flexiondotorg | We also provide a page where every source is presented to the user. | 20:28 |
| slangasek | flexiondotorg: yes; this is not the same thing as an in-band confirmation from the user before they change the archive security properties of their system | 20:29 |
| flexiondotorg | infinity: I'm happy to ship keys with Boutique. | 20:29 |
| slangasek | flexiondotorg: do you also ship apt pins? | 20:29 |
| flexiondotorg | I'm happy to present a more prominent indication to users that packages are coming from a 3rd party and not supported by Ubuntu. | 20:29 |
| slangasek | (I'm asking because I think that would be a good idea; third-party apt repos have terrible security implications and apt pinning can mitigate against certain kinds of accidents, but not against a truly malicious repo) | 20:30 |
| flexiondotorg | We are not adding random PPAs or 3rd party repos. They are being vetted. | 20:31 |
| flexiondotorg | And some of those repos can be replaced with snaps from the same vendors now. The snap support is landing soon. | 20:31 |
| slangasek | flexiondotorg: but they're not being vetted by either the TB on behalf of the Ubuntu Developers, or by the user when they select for installation, and that's the problem from my perspective :) | 20:31 |
| slangasek | flexiondotorg: to be clear, I don't want to ask you to cripple any functionality here | 20:32 |
| slangasek | but I do think the security implications need to be surfaced to the user | 20:32 |
| stgraber | sure but any of them being taken over by a malicious third party and all your users are screwed with no way for you to fix them, downloading those keys over http then makes it even worse as it becomes pretty easy for someone to just feed you some other keys they'd like you to trust... | 20:32 |
| flexiondotorg | I understand. I'm keen to retain the functionality is a fashion the TB is comfortable with. | 20:33 |
| flexiondotorg | I just wanted to make it clear we are being careful with the 3rd poarty repos we select. | 20:33 |
| stgraber | For deb packages, I expect the minimum would be to have the GPG key in question in your package, ship apt pinning config so that they can't push any package other than what you expect AND you should still show a very clear message to the user that they're effectively trusting vendor XYZ with root on their system. | 20:34 |
| infinity | ^-- I think that about sums it up for me. | 20:34 |
| slangasek | right, +1 | 20:34 |
| flexiondotorg | I wasn't aware Boutique was doing anything it shouldn't. My only intention was to provide the software user want with an easy install. | 20:34 |
| infinity | And that message can't be a one-time "I trust you to do stupid things for me", but triggered on any new repo enablement. | 20:35 |
| flexiondotorg | I'm happy to ship keys in the application, if that is desirable. | 20:35 |
| infinity | "I explicitly trust Google Chrome's repo" one day and "I also explicitly trust Dave's Janky PPA" the next. | 20:35 |
| flexiondotorg | Boutique is a snap now. So we do have a means to act quickly should a repo become compromised in some fashion. | 20:35 |
| flexiondotorg | We can notify users and provide corrective action. | 20:36 |
| infinity | flexiondotorg: Shipping keys in the package is the easiest way to maintain a reasonable trust path. It also makes it easier for you to revoke them in an SRU. | 20:36 |
| flexiondotorg | As I said, it will land as a snap so we can revoke them promptly via an update should the need arise. | 20:36 |
| infinity | (Has anyone else found it very difficult to correctly type the word "trust" ever since, oh, October 2013 or so?) | 20:37 |
| mdeslaur | heh | 20:38 |
| flexiondotorg | So, ship keys. Apt pinning. Up front indication that 3rd party packages are not supported by Ubuntu. | 20:38 |
| flexiondotorg | Shipping keys and upfront indication are quick work. Apt pinning will take a little longer. | 20:39 |
| infinity | flexiondotorg: Not just lack of support, but also indicating each time someone enables a new repo that they are explicitly trusting that non-Ubuntu repository with root on their system. | 20:39 |
| stgraber | it's really not just that they're not supported by Ubuntu, I mean universe packages would kinda fit that description, it's more "I'm trusting that vendor with full root access to my system" | 20:39 |
| flexiondotorg | Understood. | 20:40 |
| infinity | flexiondotorg: Anyhow, I think the next action here would be for you to come up with a design plan, toss it at the mailing list for review, and move this forward there. | 20:40 |
| infinity | I expect there might be some iteration. | 20:41 |
| infinity | Though, happy to be proven wrong. | 20:41 |
| flexiondotorg | OK | 20:42 |
| infinity | #action flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns. | 20:42 |
| meetingology | ACTION: flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns. | 20:42 |
| infinity | Aaaand, on we go. | 20:42 |
| infinity | #topic Mailing List Archives | 20:42 |
| infinity | So, other than the bits we just talked about, there's a Kylin repo revisiting thing, that I think can be addressed on-list. | 20:43 |
| infinity | And a PPU request. Did anyone action that? | 20:44 |
| infinity | slangasek: Did. | 20:44 |
| infinity | Minus the colon. | 20:44 |
| slangasek | yeah, about 30 minutes ago ;) | 20:44 |
| infinity | Heh. | 20:44 |
| infinity | #topic Community Bugs | 20:44 |
| infinity | GUYS WE HAVE ONE. | 20:44 |
| slangasek | OMG | 20:45 |
| mdeslaur | WAT? | 20:45 |
| slangasek | who wants it? :) | 20:45 |
| stgraber | can't be | 20:45 |
| slangasek | it's just another edit-acl | 20:45 |
| infinity | "Adding people to that packageset depends on team reorg in the set of teams for Ubuntu Budgie development (or the creation of a new team for it), the Developer Membership Board will take care of the following steps." | 20:45 |
| infinity | Looks like it's spinning wheels waiting on that, though? | 20:45 |
| infinity | I mean, a packageset with no members seems pointless. | 20:45 |
| slangasek | if it avoids the DMB blocking on the TB, it's not pointless IMHO | 20:46 |
| infinity | That's fair. | 20:46 |
| infinity | slangasek: All yours, if you want to spend the copious amount of time verifying that copy-paste and pasting it. | 20:46 |
| infinity | #topic Chext Nair | 20:47 |
| slangasek | e... d... i.... r... shoot | 20:47 |
| infinity | Looketh like iz kees, mit mdeslaur backup. | 20:47 |
| mdeslaur | ack | 20:47 |
| infinity | #topic AOB | 20:48 |
| * mdeslaur gives stink-eye to kees | 20:48 | |
| infinity | Anyone have any OB to gab about? | 20:48 |
| infinity | Other than the minor excitement over having an actual meeting with stuff in it for once? | 20:48 |
| slangasek | I do have one thing more | 20:48 |
| infinity | Excellent. Thing away. | 20:48 |
| infinity | #topic Steve has a thing | 20:48 |
| slangasek | I started a thread on ubuntu-devel to discuss policy around snaps preinstalled on Ubuntu images | 20:49 |
| slangasek | I think this should eventually go to TB for signoff | 20:49 |
| infinity | That it should. | 20:49 |
| mdeslaur | +1 | 20:49 |
| slangasek | any preference on what form that should take? | 20:49 |
| slangasek | should I put it on agenda for next meeting, or would you prefer email? | 20:49 |
| infinity | One with an explicit sign-off from Mark that our jobs are safe if we dislike the plan. | 20:49 |
| infinity | *cough* | 20:49 |
| mdeslaur | heh | 20:50 |
| infinity | But yes, I think on agenda and real-time discussion. | 20:50 |
| slangasek | (I still need to incorporate feedback from the mailing list thread before submitting to TB) | 20:50 |
| slangasek | ok | 20:50 |
| infinity | Any other any other any other bidness? | 20:51 |
| infinity | 3 | 20:51 |
| infinity | 2 | 20:51 |
| infinity | 1 | 20:51 |
| infinity | #endmeeting | 20:51 |
| meetingology | Meeting ended Tue Feb 27 20:51:22 2018 UTC. | 20:51 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2018/ubuntu-meeting-2.2018-02-27-20.01.moin.txt | 20:51 |
| slangasek | thanks, all! | 20:51 |
| mdeslaur | thanks everyone | 20:51 |
| infinity | Wiki updated, and I'm out. | 21:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!