[00:52] <liuxg>  I am now trying to development a simple snap app on 16.04 desktop. I met a problem. whenever install my snap app onto my desktop, it takes quite a lot of space since I get all of the Qt stuff. the problem is that it get different versions in my hard disk, and each takes that space. How can I remove the versions that i do not need any more? thanks
[03:26] <nhaines> ls
[06:33] <zyga> o/
[07:55] <shuduo> ogra_: hello, may i know where is official kernel repo for rpi2 snappy image?
[08:37] <ogra_> shuduo, ppisati maintains it on kernel.ubuntu.com (i always forget the exact branch name)
[08:37] <shuduo> ogra_: got it. let me find it. :)
[08:46] <shuduo> ppisati: ping
[10:37] <ppisati> shuduo: pong
[11:17] <shuduo> ppisati: may i know what kernel tree and branch is being used for snappy on raspberry pi 2?
[11:37] <shuduo> ppisati: i cloned it from  git://git.launchpad.net/~p-pisati/ubuntu/+source/linux and see   remotes/origin/x-raspi2
[11:37] <shuduo>   remotes/origin/x-raspi2_rtlfix
[11:37] <shuduo>   remotes/origin/x-raspi2_rtlwififix
[12:07] <kyrofa> Good morning
[12:10] <qengho> jdstrand: what does the "unconfined" security plug look like these days? Still old-security?
[12:40] <jdstrand> qengho: it looks like --devmode :)
[12:41] <jdstrand> qengho: more seriously, it was decided that unconfined isn't a thing any more
[12:41] <jdstrand> people can use --devmode to be unblocked and file a bug for what they need (please add snapd-interface tag)
[12:45] <ppisati> shuduo: that's my personal git tree
[12:46] <ppisati> shuduo: use this:
[12:46] <ppisati> shuduo: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=raspi2
[12:59] <shuduo> ppisati: got it. thanks.
[13:38] <morphis> jdstrand: first step towards slot support in the pulseaudio interface: https://github.com/morphis/snappy/commit/08da30f860ab68cf9ed866e10874e8b353894d36
[13:38] <morphis> needs cleanup and then I will push that as PR next week
[13:40] <niemeyer_> ssweeny: ping
[13:42] <jdstrand> morphis: nice! :)
[13:44] <morphis> jdstrand: however policy might be too in open in some points, we need to figure those things out once I open the PR
[13:45]  * jdstrand nods
[14:37] <Kristbaum> Hello people, is it intentional that the same snap can be run multiple times at once? E.g the Telgram-Snap can be executed 50 times on my system.
[14:39] <ogra_> file a bug ... i guess that needs some discussion
[14:40] <ogra_> (if it was a terminal app you probabl ywould want it to start multiple times .... apps that use login credentials probably not so much ... might need a field in snap.yaml/snapcraft.yaml for the dev to define)
[14:58] <Kristbaum> Can I also file a bug, concerning the "repoducable Builds" thing, or would this be more anoying, than helpful?
[15:01] <kyrofa> Kristbaum, are you talking about bug #1582417
[15:05] <Kristbaum> Oh, very nice, I thought I needed to create one first ;) Is there also one about linking to sources, so that you can verify, that you are running the correct software (in case it's opensource), or did I also miss that?
[15:10] <kyrofa> Kristbaum, not that I know of
[15:12] <ogra_> thats really up to the developer, iirc the store app page pffers you to specify a source url and homepage when you register your snap
[15:14] <Kristbaum> ogra_: But the source on the Website doesn't have to macht the final snap image, right?
[15:14] <ogra_> nothing has to match a snap ... but if you are OSS developer you can indeed specify your git tree and homepage
[15:15] <ogra_> snaps really only care about binary ...
[15:15] <ogra_> everything else would be added meta data for the store side
[15:16] <ogra_> there arent even any requirements that you have the source for what you put inside your snap (assumed you are allowed to distribute it indeed)
[15:21] <Kristbaum> Okay, and we can agree that is a problem? Because, e.g. there is a Telegram app out there (wich I cant find the source for), how do I know it isn't sending out all I write to somebody? Or another example: The Keepassx snap, can't send anything because it has no network plug, but but how do I know if it really encrypts it correctly?
[15:29] <ogra_> you dont
[15:32] <ogra_> (afaik that telegram app is actually the binary from telegram.org ...)
[15:33] <Kristbaum> ogra_: okay so this is a problem.. Should I bug report this, or is this more of a management decision?
[15:33] <ogra_> i dont see where it is a problem
[15:34] <ogra_> the snap design is only built around binaries ... how you produce them is in your responsibility
[15:34] <ogra_> it tries to give everyone the most freedom it can ... by not enforcing such stuff
[15:35] <ogra_> what it enforces is the security model ... no app should be able to access any data or service you havent explicitly authorized
[15:37] <ogra_> weather the source code that binary was initially built from is open or not doesnt matter ... a good OSS dev would indeed mention where the code comes from and give you a reciepe how it is built ... but thats totally not mandatory
[15:39] <Kristbaum> I think the whole concept (at the moment), works really great for proprietary software. But for Free Software people, and Security minded ones it isn't really a step forward, because you can't check the software you are using. Isn't this a contrast to the whole security story?
[15:39] <ogra_> well, you cant check whet the single binary does, but you have full control about its outside connections
[15:40] <ogra_> be it disk, network, sensors on your phone or whatever
[15:41] <Kristbaum> Thats right, but in a OSS binary I want to trust the binary too. And I can't if i can't verify if it's the same code as on the website.
[15:42] <ogra_> you can if the developer tells you how it was built and points you to the source code
[15:43] <ogra_> if you are concerned about that you will have to check the details of the respective snaps you use
[15:44] <ogra_> but after all, do you actually do that for ... say the desktop you use ?
[15:44] <ogra_> i.e. do you know the filemanager you use doesnt come with a keylogger inside
[15:47] <Kristbaum> Thats right, but considering that it's quite easy in apt, snaps are kind of a step back. There is a really high chance that somebody will build a malicous e.g. Telegram app and there will be no checks possible, and when sobody finds out it will be a mess etc.. And no ofcource I am to lazy to ever check the source of my software, but I trust you and all the other Ubuntu/Debian developers that they have access to th
[15:48] <ogra_> well, the hope is indeed that telegram uses a snapcraft.yaml in its tree and simply provides an official snap
[15:54] <Kristbaum> We woudn't need to hope on every company to to this, if there would be something like a automated trustet OSS snap build service, where oss developers provide a link to the source and a .yaml file, and it gets built, and we can check it if needed with something like snap source telegram-sergiusens.
[15:55] <ogra_> thats called launchpad ;)
[15:55] <ogra_> (such an LP feature exists already)
[15:55] <ogra_> but still, it is optional
[15:56] <ogra_> the telegram-sergiuens snapcraft.yaml wouldnt help you much though ... i'm 90% sure it doesnt build the source
[15:56] <ogra_> afaik it just pulls the latest binary from upstream and snaps it
[15:57] <Kristbaum> But the Version in the store already is behind?
[15:57] <ogra_> and there will likely be many snapcraft.yaml files like this
[15:57] <oparoz> LP snap builders, when they work, are great. You can even build partials
[15:57] <ogra_> did they stop working ?
[15:58]  * ogra_ hasnt had issues yet
[15:58] <ogra_> Kristbaum, well, ask sergiusens :)
[15:58] <ogra_> if he feels like updating
[15:59] <ogra_> or just hit the update button inside the running app ;)
[15:59] <Kristbaum> But still, can people check if they want to, with this LP plugin?
[15:59] <ogra_> sure
[15:59] <Kristbaum> the Update Button chrashes it :D
[16:00] <Kristbaum> Maybe it is malicions :D
[16:00] <ogra_> it gets updated, but cant restart for whatever reason
[16:00] <ogra_> if you start it newly it is up to date
[16:01] <Kristbaum> Nope, it's the same as before
[16:01] <ogra_> https://code.launchpad.net/~ogra/+junk/ircproxy is a branch of mine (bit outdated, i'm waiting for "snap config" to come back) ...
[16:01] <ogra_> https://code.launchpad.net/~ogra/+snap/ircproxy are the snap packages created from that branch
[16:01] <ogra_> on the branch summary page i have a "build snap" button ...
[16:08] <Kristbaum> Interesting indeed. But there is still the risk of a malicous person taking x/y oss app (modify it in a bad way), load it up in the store, and noone would notice. Snaps are a redirection of trust in the hands of the person that uploads it, and non officail app can be trusted.
[16:09] <ogra_> it depends ... i assume if you woulld use a snappy based desktop install you would still trust canonical as much as you do today
[16:09] <jdstrand> Kristbaum: to expand on/reiterate what ogra said: snappy itself doesn't enforce anything regards to sources or builds from source, just like debs don't either. snaps and debs are a packaging format. Launchpad is used to build Ubuntu binaries from deb source packages. Launchpad has facilities for building snaps from source packages as well
[16:10] <ogra_> and that PPA guy from whom you install packaages to your system ... you trust him enough to give him root on your machine
[16:10] <jdstrand> Kristbaum: and aiui there are plans to make building from sources even easier for open source projects and devs
[16:10] <ogra_> it shuffles the trust around indeed ... but also adds a massive amount of safety and security in the end
[16:11] <Kristbaum> No way :D That also no a good solution but at least I can go to the launchpad site and check it, and I know it is the same, as is running on my system.
[16:13] <jdstrand> Kristbaum: then there *will* be a way to verify the origin-- there will be sha512 sums of the generated snap that can be compared against Launchpad, etc
[16:13] <ogra_> and if an OSS dev wants you to have that info today he can already put a link to the tree and a build HOWTO in the package description
[16:13] <jdstrand> and aiui, all this is going to get easier and better
[16:13] <ogra_> jdstrand, well, the origin for the binary
[16:14] <ogra_> i can slap a bunch of downloaded binaries together in a snap and just upload them from my desktop ... you can probably track it to me via that ... but you wont know if i built a thing of it from source
[16:14] <jdstrand> ogra_: I'm saying that if someone uploads a source/build from source, the resulting binary's sum can be verified against what is installed on the device
[16:14] <ogra_> indeed
[16:14] <jdstrand> uploads and builds on LP that is
[16:14] <ogra_> but so can my binary blob collection
[16:15] <ogra_> ah
[16:15] <ogra_> right, if you build it there too, thats indeed different
[16:15] <jdstrand> so a security minded person might make a personal or site-specific decision-- I will only install snaps that are built on LP, etc
[16:15] <ogra_> right
[16:16] <jdstrand> I can imagine snapd and the store gaining functionality to make that all convenient
[16:16] <Kristbaum> Okay, thats a start ;) I really love the snappy concept in every way, this is the only thing that still bothers me. I think it's great that I will be able to at least check projects build on lp,
[16:16] <Kristbaum> And marking the trusted OSS snaps would be nice to
[16:17] <jdstrand> reproducible builds and builds from source are important concepts that will be supported. the minimum bits are, more will come
[16:19] <Kristbaum> I know you have a lot to do these days, I just hope noone gets bad ideas and builds malicious snaps. Because this could really damage the reputation early one, despite it beeing a grat idea.
[16:20] <ogra_> i actually hope people do :)
[16:20] <ogra_> it will prove the security setup
[16:20] <Kristbaum> Maybe we should do a challenge to try and test the limity of snappy.
[16:20] <ogra_> definitely ... and indeed file bugs for everything
[16:22] <Kristbaum> The snappy challenge, who can get the most keyloggers to people :D Has UBuntu-Marketing an IRC channel?
[16:22] <ogra_> well, keylogger and Xorg vulnerabilities would be a bit unfair until Mir is there
[16:22] <ogra_> since it is a known open hole
[16:22] <Kristbaum> okay, fair point
[16:23] <ogra_> i'd start with a headless challenge ;)
[16:27] <Kristbaum> Would In-App-Keyloggers be allowed?
[16:28] <ogra_> why not
[16:29] <Kristbaum> ok, maybe I find somebody in marketing that likes the idea :D
[16:31] <ogra_> :)
[17:01] <ssweeny> niemeyer_, sorry I missed your ping earlier
[17:32] <slvn> Hello! Just wondering about this issue which seems to lack attention. Some snap can't be validated because of invalid checksum ... https://bugs.launchpad.net/ubuntu/+source/squashfs-tools/+bug/1577333
[17:33] <kyrofa> jdstrand, how do the review tools check that ^^? Uncompress and recompress and compare checksums?
[17:34] <ogra_> do you need to uncompress ?  the sum should be in the meta data ...
[17:34] <ogra_> so you just need to compare the squashfs sum vs meta
[17:35] <kyrofa> ogra_, ah, I didn't realize that. What would cause them not to match?
[17:35] <ssweeny> jdstrand, if I'm writing a dbus rule to allow getting/setting a particular property what would that look like? Would the interface be /com/ubuntu/location/service/<property> or would it be /org/freedesktop/dbus/properties with the destination com.ubuntu.location.service.<property>?
[17:35] <ogra_> recompressing them ??
[17:35] <ogra_> dunno
[17:38] <jdstrand> kyrofa: there are 3 bugs related to this that I'll be getting to after the interfaces, doc and devmode work
[17:38] <kyrofa> jdstrand, ah, okay. I just noticed that you reassigned to squashfs-tools, so you must know what's going on there. I wasn't sure if snapcraft was doing something wrong or what
[17:39] <kyrofa> slvn, ^^ FYI
[17:39] <jdstrand> kyrofa: to answer your question specifically, I updated squashfs-tools to add an option to unsquashfs to grab the fs time from a snap. then I added an option to mksquashfs to injuect that time into the superblock. in this manner, we can resquash
[17:39] <jdstrand> kyrofa: however, there are a couple of issues where timestamps are causing trouble, and perhaps something not timestamp related
[17:40] <jdstrand> no, snapcraft is fine
[17:40] <kyrofa> jdstrand, ah, I see, okay
[17:40] <jdstrand> it works a lot of the time but unfortunately it isn't 100% yet
[17:42] <slvn> kyrofa, I don't fully understand ... it seems to me *all* my packages systematically fails the checksum test.
[17:43] <jdstrand> slvn: you might be hitting one of the three different bugs
[17:44] <slvn> jdstrand, hmm ok! so all is under control :)
[17:44] <jdstrand> I'll be updating the review tools for something else, I should turn this check off until it is reliable
[17:45] <jdstrand> well, yes, though it'll still be a little while before it is fixed. but let me make it better for people
[17:45] <jdstrand> (ie, make the check temporarily non-fatal
[17:45] <jdstrand> )
[17:54] <jdstrand> tyhicks, beuno: fyi, I just committed 'turn resquash test into info for now until the squashfs-tools bugs are fixed and this is a reliable check' to address ^
[17:58] <tyhicks> jdstrand: ack - I hope we can get to those bugs soon and reenable the checks
[17:58] <jdstrand> me too :|
[18:15] <beuno> jdstrand, ack
[18:29] <ssweeny> jdstrand, for the location-control interface I have apparmor rules that enable "{Get,Set}" for properties. You mentioned expanding the dbus rules as well but I'm not sure what that should look like
[18:39] <jdstrand> ssweeny: I was only saying that in general-- ie, whatever org.freedesktop.... accesses you might need to have Get and Set work
[18:39] <jdstrand> ssweeny: maybe that is nothing beyond what the dbus abstractions already give (I just didn't know)
[18:39] <jdstrand> ssweeny: (when location-control is standalone)
[18:39] <ssweeny> jdstrand, ah, that makes more sense. I don't think it's possible to do what I thought you meant (i.e. enumerate the properties themselves in the policy)
[18:40] <jdstrand> ssweeny: oh no, we can't mediate on message contents, no
[18:41] <ssweeny> jdstrand, ok, thanks!
[21:17] <jdstrand> roadmr (cc beuno, nessita and tyhicks): can you pull r664 of the review tools for devmode support?
[21:17] <jdstrand> roadmr: and hi! :)
[21:18] <roadmr> jdstrand: sure! I'll work on it, hello :)
[21:18] <jdstrand> roadmr: it can be next week if needed
[21:18] <jdstrand> roadmr: thanks :)
[21:18] <roadmr> jdstrand: well it's fri evening so unless we escalate the hell out of it, it will be next week :(
[21:18] <roadmr> jdstrand: I'll get the ball rolling though :)
[21:19] <jdstrand> hehe
[21:20] <jdstrand> roadmr: right, please don't escalate the hell out of it :)
[21:20] <jdstrand> hehe
[21:20] <roadmr> \o/ thanks :)