20:01 <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> 
20:01 <meetingology> Available commands: action commands idea info link nick
20:01 <infinity> So, who's here?  Do we have quorum?
20:02 * stgraber waves
20:02 <infinity> We do!
20:02 <mdeslaur> wow! hi stgraber!
20:02 <infinity> #topic Action Review
20:03 <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:04 <infinity> Budgie LTS status, that seems to have been handled on-list, unless we want a quorum vote taken?
20:05 <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:06 <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:07 <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:08 <tsimonq2> (Ubuntu MATE)
20:08 <tsimonq2> UKUI is a fork of MATE
20:08 <infinity> Ahh, or that.
20:09 <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:10 <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:11 <slangasek> i
20:11 <infinity> So it is.
20:12 <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:13 <tsimonq2> Correct, that's the goal.
20:14 <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:15 <tsimonq2> But is the TB OK with that plan?
20:16 <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:17 <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:18 <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:19 <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:20 <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 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:21 <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:22 <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:23 <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:24 <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:25 <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:26 <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:27 <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:28 <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:29 <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:30 <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:31 <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:32 <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:33 <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:34 <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:35 <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:36 <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:37 <infinity> (Has anyone else found it very difficult to correctly type the word "trust" ever since, oh, October 2013 or so?)
20:38 <mdeslaur> heh
20:38 <flexiondotorg> So, ship keys. Apt pinning. Up front indication that 3rd party packages are not supported by Ubuntu.
20:39 <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:40 <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:41 <infinity> I expect there might be some iteration.
20:41 <infinity> Though, happy to be proven wrong.
20:42 <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 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:43 <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:44 <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:45 <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:46 <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:47 <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:48 <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:49 <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:50 <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:51 <infinity> Any other any other any other bidness?
20:51 <infinity> 3
20:51 <infinity> 2
20:51 <infinity> 1
20:51 <infinity> #endmeeting