19:04 <kees> #startmeeting
19:04 <meetingology> Meeting started Tue Apr 10 19:04:35 2018 UTC.  The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
19:04 <meetingology> 
19:04 <meetingology> Available commands: action commands idea info link nick
19:04 <kees> ah
19:05 <kees> action review:
19:05 * kees flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns.
19:05 <slangasek> I haven't seen anything on the list
19:05 <mdeslaur> doesn't look like he did
19:06 <slangasek> and he's currently off irc
19:06 <kees> yeah
19:06 <tsimonq2> Wimpress is his new nick.
19:06 <slangasek> oh
19:07 <slangasek> Wimpress: ^^ ?
19:07 <Wimpress> o/
19:07 * kees tsimonq2 to propose patches to maintenance-check regarding Lubuntu Next (done in https://code.launchpad.net/~tsimonq2/ubuntu-archive-publishing/lubuntu-next-support-cycle-adjustment/+merge/342475
19:07 <kees> oh
19:07 <Wimpress> This is not forgotten.
19:07 <Wimpress> I'll try and get round to this in the next week.
19:07 <mdeslaur> Wimpress: what's with the disguise?
19:07 <tsimonq2> mdeslaur: #blameflocculant
19:07 <Wimpress> Long story.
19:07 <mdeslaur> hehe
19:07 <Wimpress> But that ^
19:08 <Wimpress> We've already dropped a bunch a PPA and repos from Welcome as a start on  this.
19:08 <Wimpress> But I will post to the ML with a full proposal soon
19:09 <mdeslaur> ack, thanks
19:09 <kees> cool. deferred
19:10 <slangasek> Wimpress: ok; bearing in mind that the TB's request was not that you drop the support for third-party repos necessarily, but that you disclose to the user what is happening
19:10 <kees> tsimonq2: how about your action?
19:10 <Wimpress> slangasek: Yes, I know. But I felt this was a good time to review what we were listing.
19:11 <tsimonq2> kees: It's done; I'm the one who modified the agenda with the link in there. ;)
19:12 <slangasek> yes, I reviewed and merged the change
19:12 <slangasek> tsimonq2: have you verified that the result is correct in the archive metadata?
19:12 <kees> oh durp
19:12 <tsimonq2> slangasek: No; where can I do that?
19:12 <slangasek> tsimonq2: Packages.gz
19:13 <slangasek> tsimonq2: Supported field
19:13 * kees infinity to call for confirmation of LTS status from all flavours.
19:13 <tsimonq2> One minute then; you're free to move on to other items.
19:13 <kees> no infinity so deferred
19:14 <slangasek> tsimonq2: qlubuntu-default-session still shows as Supported: 3y which I think indicates it didn't have the intended result yet; you and I can iterate
19:14 * kees infinity to ask maas team to prepare SRU exception policy à la CurtinUpdates
19:14 <kees> also deferred
19:14 <kees> agenda items...
19:15 <kees> [slangasek] - Review of the seeded snaps policy
19:15 <slangasek> hello
19:15 <slangasek> [LINK] https://wiki.ubuntu.com/UbuntuSeededSnaps
19:15 <tsimonq2> slangasek: The source package is shared. That's not an accurate representation.
19:15 <slangasek> tsimonq2: afaik supported fields are per-binary, not per-source; anyway, feel free to find one that you know should be 9m and check the result :)
19:16 <slangasek> kees, mdeslaur: I didn't send any follow-up emails, I think the agreement last time was that TB members would review this spec in their own time and we could discuss at this meeting.  Did you have a chance to review the spec?
19:16 <mdeslaur> I did review the spec, I have a few questions
19:17 <tsimonq2> slangasek: Ah, so indeed, it didn't set correctly.
19:17 <tsimonq2> #action tsimonq2 to investigate why the Lubuntu Next support time modifications are not set correctly
19:17 * meetingology tsimonq2 to investigate why the Lubuntu Next support time modifications are not set correctly
19:18 <tsimonq2> Anyway, sorry, carry on.
19:18 <slangasek> mdeslaur: excellent, I'm happy to make up answers :)
19:19 <mdeslaur> The spec doesn't define who acts as the gatekeeper between core devs and publishing a snap directly to users
19:19 <mdeslaur> like the way it is currently handled
19:19 <slangasek> in the sense of archive review?
19:20 <mdeslaur> yes. In the sense that currently a core dev can't push an update directly to users
19:20 <slangasek> ah; so perhaps more in the sense of SRU
19:20 <mdeslaur> without going through the sru team, etc
19:21 <slangasek> yes; I think the design of the snap store, and the relative isolation of snaps, means we should aim to have less process around this generally,
19:22 <slangasek> because e.g. reverts are a lot easier, and eventually should be drivable with health checks
19:22 <slangasek> etc
19:22 <slangasek> so at this time I wasn't aiming to dictate any gatekeeping around this, or to forklift import the SRU policy
19:23 <kees> i only had one question: how are seeded snaps distinguished from third party snaps? given the higher policy requirements for seeded snaps, end users may only want seeded snaps
19:24 <slangasek> mdeslaur: do you think that's ok for now, or do you think we need gatekeepers initially?
19:24 <mdeslaur> won't there be third party seeded snaps too?
19:25 <mdeslaur> slangasek: I personally think this makes becoming a core-dev or attempting to steal core-dev credentials much more attractive for people with bad intentions
19:25 <slangasek> ok
19:25 <kees> mdeslaur: seeded snap policy says everything has to be in LP (source and builds), so i think no 3rd party?
19:26 <mdeslaur> "...to be included in an Ubuntu image, a snap should have as its publisher either the upstream..."
19:27 <slangasek> mdeslaur: in practice, we don't gate uploads to the devel series by core-devs, after initial NEW processing; so it's a difference in window of opportunity (you can upload a hostile snap and have it instantly take effect for stable users, vs. having to upload to devel and wait and see)
19:27 <jbicha> that's interesting for the use case of Firefox where we got mozilla building the snap
19:27 <slangasek> mdeslaur: and in practice the store doesn't give us many layers of gatekeeping against collaborators
19:27 <mdeslaur> slangasek: right, but the devel series is a buffer that (in theory) allows review by others, and damage can be reverted before hitting users
19:28 <slangasek> kees: so in this case you're defining third-party as "not built on trusted infrastructure"?
19:29 <kees> i guese, yes. "snaps installed by default we should ensure that they are built from source in the same trusted Launchpad environment in which debs are built"
19:29 <slangasek> yes, firefox is an interesting case, and there are different requirements that are in tension.  I think we should punt on firefox in the context of this discussion
19:31 <slangasek> (firefox snap is not seeded in 18.04 desktop, AFAIK; we have time)
19:31 <kees> the policy (source can't disappear, built on LP) is a higher bar, so making those discoverbale seems like it'd have value to end users
19:31 <kees> beyond that, i like the policy
19:31 <slangasek> kees: anyway, to your question of distinguishing them, the intent is that this be surfaced as metadata in the snap store, which the store could expose to the end user over the snapd api
19:32 <kees> perfect
19:32 <jbicha> (yes, AFAIK firefox snap isn't proposed for inclusion in Ubuntu by default yet)
19:32 <slangasek> I'm working with the store team on the implementation details, but yes, it's important that this be auditable and not taken on faith that a given snap is done correctly :)
19:32 <kees> mdeslaur: are your questions/concerns addressed?
19:32 <mdeslaur> I like the policy as it applies to snaps built in launchpad from known sources, and security support has been commited to
19:33 <mdeslaur> I don't know how third party or upstream snaps fit into that
19:33 <slangasek> mdeslaur: per current policy, a "third party" or "upstream" snap is fine but they still need to build the binary on LP to comply with this policy
19:34 <mdeslaur> how the mechanism for taking control of that snap if adequate security isn't being provided?
19:34 <mdeslaur> s/how/what's/
19:35 <jbicha> (and the third party needs to be in a LP team approved by the DMB)
19:36 <mdeslaur> Let's say we allow an upstream snap, built on launchpad in bionic, and upstream decides to no longer build security updates for the bionic snap once the next LTS rolls out, for example
19:36 <slangasek> mdeslaur: today, we would try to talk to the publisher first, or the store team as necessary, to get collaborator access and publish our updates to the stable/ubuntu-XX.YY channels
19:37 <slangasek> jbicha: that's an interesting point; I don't think it follows from the current policy as written
19:37 <kees> slangasek, mdeslaur: sounds like security support policy needs to get fleshed out more? should that continue in email?
19:38 <jbicha> slangasek: oh
19:38 <slangasek> note that the snap store doesn't actually use launchpad teams; publishers / collaborators are implemented only store side and are defined in terms of assertions and keys
19:38 <slangasek> so we can't actually enforce that every collaborator on a third-party snap is part of a DMB-approved LP team
19:40 <kees> [action] slangasek and mdeslaur to more clearly define third party seeded snap security policy
19:40 * meetingology slangasek and mdeslaur to more clearly define third party seeded snap security policy
19:40 <kees> how's that look?
19:41 <slangasek> if that is the action from mdeslaur's POV, sure :)
19:41 <mdeslaur> It may be easier to get this accepted in two steps: 1- community-maintained, launchpad-built snaps, and then 2- thirty party snaps
19:41 <kees> 20 minutes left, so let's move on for now...
19:41 <kees> [tsimonq2] - The rationale for snapd being in the platform seed when flavors weren't polled first.
19:42 <mdeslaur> ok
19:42 <tsimonq2> Hi.
19:42 <tsimonq2> I am wondering, out of curiosity, why snapd was added to the desktop-common seed without flavors being consulted: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/revision/2056
19:42 <tsimonq2> I oppose to shipping snapd in Lubuntu by default due to some serious usability concerns that I have raised with the Snapcraft team, as well as bug 1730159 among other things.
19:42 <tsimonq2> This isn't an issue right now, because Lubuntu doesn't pull in recommends and I've manually blacklisted it just in case, but it becomes an issue when we turn off no-follow-recommends at the beginning of next cycle.
19:42 <tsimonq2> I would like to request the removal of snapd from desktop-common, even as recommended, because Lubuntu does not want to ship this as part of our default install, unless of course it's mandated by the Technical Board. I would also like to know why this decision was made without asking flavors, unless I am missing some historical context or something else here.
19:43 <tsimonq2> Thanks.
19:44 <slangasek> right
19:45 <slangasek> so, I have certainly defended the principle recently that the desktop-common seed in particular should be subject to consensus among the desktop flavors, and should not be used to force things into the common platform over objections ;)
19:45 <tsimonq2> You have. :)
19:45 <slangasek> you will however note that I am the committer of that revision and are right to call out the disconnect
19:45 <slangasek> so here's my position
19:46 <slangasek> the fact that it's in the desktop-common seed is actually an implementation detail
19:46 <slangasek> from the perspective of Canonical, and the Foundations Team, snapd is now part of the standard Ubuntu experience
19:47 <slangasek> anyone who installs Ubuntu, in any of its forms, should be able to 'snap install' the same way they're able to 'apt install'
19:47 <slangasek> in practice it's separately seeded in desktop-common and in server, but the intent is that it's part of the common platform experience
19:47 <slangasek> this is subject to TB review, of course
19:48 <tsimonq2> Right, and this is me bringing it to TB review. :)
19:48 <kees> seems like snapd should be part of the per-flavor *-desktop ?
19:48 <slangasek> but that at least gives the rationale for not consulting flavors - it was a platform-level decision
19:48 <kees> or *-minimal, or something?
19:49 <tsimonq2> And the "standard Ubuntu experience" is defined by Canonical, not by the Ubuntu Technical Board or another similar body? Or does this come from sabdfl?
19:49 <slangasek> depending on the result of TB review, we can move it to a more appropriate seed(s) for clarity
19:49 <slangasek> tsimonq2: the TB doesn't often get asked to sign off on platform changes up front
19:50 <slangasek> I don't think the upstart->systemd move was TB-ratified, to give one example
19:50 <tsimonq2> kees: I agree with you.
19:50 <slangasek> but the TB is certainly the right forum for appeal
19:50 <kees> seems like even this doesn't need to come to TB. snap availability should be a flavor-specific option, yes?
19:51 <kees> slangasek: by "standard Ubuntu experience" do you mean "all ubuntu flavors"?
19:51 <tsimonq2> kees: Correct, but we weren't given the choice.
19:51 <slangasek> kees: yes
19:51 <kees> aaah
19:51 <kees> hm
19:51 <mdeslaur> just like all flavours use the standard kernel, and repos, etc.
19:51 <kees> right
19:52 <kees> okay, I misparsed the "standard Ubuntu" to mean "Ubuntu-the-flavor"
19:52 <tsimonq2> But, "standard Ubuntu experience" is Canonical-defined? Is that at least public?
19:52 <kees> You really mean "universal Ubuntu experience"
19:52 <mdeslaur> I think it would be a disservice to users to have a specific flavour be missing some software installation sources
19:52 <slangasek> kees: yes, sorry
19:53 <tsimonq2> mdeslaur: Even if it's one command away to install and it's not being used by default, at all?
19:53 <tsimonq2> Er, s/used/utilized/.
19:53 <kees> tsimonq2: if bug 1730159 was solved, how would you feel about Lubuntu with snapd installed?
19:54 <tsimonq2> kees: Much more inclined.
19:54 <tsimonq2> But I would still take an additional look.
19:54 <mdeslaur> tsimonq2: having a webpage instruct a user to do a "snap install" but then have a special section how to do it on a specific flavour would be a disservice to users
19:54 <kees> okay, then I see two issues here: the *specific* case of snapd in Lubuntu (seemingly solved with bug 1730159 getting fixed), and the desire to have a policy on things getting added to all flavors without notification of the flavors.
19:55 <mdeslaur> tsimonq2: but if you have technical objections that can be fixed, then I'm sure they could be addressed
19:55 <tsimonq2> mdeslaur: I see.
19:55 <tsimonq2> kees: Bingo.
19:55 <kees> slangasek: you've already commented on that bug; how feasible would it be to solve this before 18.10?
19:56 <kees> tsimonq2, mdeslaur: it sounds like that for 18.04, Lubuntu will need that extra instruction, since it _isn't_ installed there currently.
19:56 <slangasek> tsimonq2: so, "does this come from sabdfl" - Canonical is his company, the company has put a lot of money into developing the snap store and experience, and therefore you can expect the barrier for overturning such a platform decision to be somewhat high (even to the point that yes, sabdfl might directly put his thumb on the scale).  As mdeslaur says, Canonical's interest here would instead be
19:56 <slangasek> to focus on improving snapd so that it met the needs of our flavors
19:56 <tsimonq2> kees: Does the TB expect me to put snapd back?
19:57 <tsimonq2> I can, if needed.
19:57 <kees> tsimonq2: I don't know; that's why I'm bringing that up -- as things stand, it's not installed. but it's a Recommend and Lubuntu doesn't install Recommends by default, so ... everything is working as expected right now
19:57 <slangasek> kees: I would say that LP: #1730159 should even be solved in 18.04 (though perhaps not before GA)
19:57 <kees> the statements made about it seem to aim at 18.10 when those defaults will change for lubuntu
19:57 <tsimonq2> slangasek: OK. I am not saying that I don't like snapd and I don't want to ship it, I'm saying that I see shortcomings to doing that before some problems are solved.
19:58 <kees> okay, almost out of time.
19:58 <kees> should we keep an action about flavor-wide default package notifications?
19:58 <tsimonq2> I think so.
19:58 <slangasek> perhaps you want to scope that to "daemons"
19:58 <tsimonq2> kees: installed by default> ack
19:59 <slangasek> since that's really the only thing that makes snapd problematic, compared to all the other changes Foundations makes unsupervised
19:59 <kees> that seems reasonable to me.
19:59 <mdeslaur> I think that's reasonable also
19:59 <tsimonq2> I can remove snapd from the Lubuntu blacklist, but if Canonical wants snapd, they can raise it to a Depends. :)
20:00 <kees> tsimonq2: are you will to write up the language for such a policy? then we can review it on email and take it to the next meeting?
20:00 <tsimonq2> Absolutely.
20:00 <kees> [action] tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common)
20:00 * meetingology tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common)
20:01 <kees> okay, that's time! :)
20:01 <kees> #endmeeting