[00:52] 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] ls [06:33] o/ === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:55] ogra_: hello, may i know where is official kernel repo for rpi2 snappy image? [08:37] shuduo, ppisati maintains it on kernel.ubuntu.com (i always forget the exact branch name) [08:37] ogra_: got it. let me find it. :) [08:46] ppisati: ping === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:37] shuduo: pong [11:17] ppisati: may i know what kernel tree and branch is being used for snappy on raspberry pi 2? [11:37] ppisati: i cloned it from git://git.launchpad.net/~p-pisati/ubuntu/+source/linux and see remotes/origin/x-raspi2 [11:37] remotes/origin/x-raspi2_rtlfix [11:37] remotes/origin/x-raspi2_rtlwififix === chihchun is now known as chihchun_afk [12:07] Good morning [12:10] jdstrand: what does the "unconfined" security plug look like these days? Still old-security? === Guest24582 is now known as devil_ [12:40] qengho: it looks like --devmode :) [12:41] qengho: more seriously, it was decided that unconfined isn't a thing any more [12:41] people can use --devmode to be unblocked and file a bug for what they need (please add snapd-interface tag) [12:45] shuduo: that's my personal git tree [12:46] shuduo: use this: [12:46] shuduo: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=raspi2 [12:59] ppisati: got it. thanks. [13:38] jdstrand: first step towards slot support in the pulseaudio interface: https://github.com/morphis/snappy/commit/08da30f860ab68cf9ed866e10874e8b353894d36 [13:38] needs cleanup and then I will push that as PR next week [13:40] ssweeny: ping [13:42] morphis: nice! :) [13:44] 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] 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] file a bug ... i guess that needs some discussion [14:40] (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] Can I also file a bug, concerning the "repoducable Builds" thing, or would this be more anoying, than helpful? [15:01] Kristbaum, are you talking about bug #1582417 [15:01] bug 1582417 in Snapcraft "snapcraft doesn't create binary-identical reproducible builds" [Undecided,New] https://launchpad.net/bugs/1582417 [15:05] 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] Kristbaum, not that I know of [15:12] 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] ogra_: But the source on the Website doesn't have to macht the final snap image, right? [15:14] nothing has to match a snap ... but if you are OSS developer you can indeed specify your git tree and homepage [15:15] snaps really only care about binary ... [15:15] everything else would be added meta data for the store side [15:16] 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] 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] you dont [15:32] (afaik that telegram app is actually the binary from telegram.org ...) [15:33] ogra_: okay so this is a problem.. Should I bug report this, or is this more of a management decision? [15:33] i dont see where it is a problem [15:34] the snap design is only built around binaries ... how you produce them is in your responsibility [15:34] it tries to give everyone the most freedom it can ... by not enforcing such stuff [15:35] what it enforces is the security model ... no app should be able to access any data or service you havent explicitly authorized [15:37] 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] 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] well, you cant check whet the single binary does, but you have full control about its outside connections [15:40] be it disk, network, sensors on your phone or whatever [15:41] 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] you can if the developer tells you how it was built and points you to the source code [15:43] if you are concerned about that you will have to check the details of the respective snaps you use [15:44] but after all, do you actually do that for ... say the desktop you use ? [15:44] i.e. do you know the filemanager you use doesnt come with a keylogger inside [15:47] 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] well, the hope is indeed that telegram uses a snapcraft.yaml in its tree and simply provides an official snap [15:54] 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] thats called launchpad ;) [15:55] (such an LP feature exists already) [15:55] but still, it is optional [15:56] the telegram-sergiuens snapcraft.yaml wouldnt help you much though ... i'm 90% sure it doesnt build the source [15:56] afaik it just pulls the latest binary from upstream and snaps it [15:57] But the Version in the store already is behind? [15:57] and there will likely be many snapcraft.yaml files like this [15:57] LP snap builders, when they work, are great. You can even build partials [15:57] did they stop working ? [15:58] * ogra_ hasnt had issues yet [15:58] Kristbaum, well, ask sergiusens :) [15:58] if he feels like updating [15:59] or just hit the update button inside the running app ;) [15:59] But still, can people check if they want to, with this LP plugin? [15:59] sure [15:59] the Update Button chrashes it :D [16:00] Maybe it is malicions :D [16:00] it gets updated, but cant restart for whatever reason [16:00] if you start it newly it is up to date [16:01] Nope, it's the same as before [16:01] 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] https://code.launchpad.net/~ogra/+snap/ircproxy are the snap packages created from that branch [16:01] on the branch summary page i have a "build snap" button ... [16:08] 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] 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] 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] 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] Kristbaum: and aiui there are plans to make building from sources even easier for open source projects and devs [16:10] it shuffles the trust around indeed ... but also adds a massive amount of safety and security in the end [16:11] 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] 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] 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] and aiui, all this is going to get easier and better [16:13] jdstrand, well, the origin for the binary [16:14] 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] 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] indeed [16:14] uploads and builds on LP that is [16:14] but so can my binary blob collection [16:15] ah [16:15] right, if you build it there too, thats indeed different [16:15] 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] right [16:16] I can imagine snapd and the store gaining functionality to make that all convenient [16:16] 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] And marking the trusted OSS snaps would be nice to [16:17] reproducible builds and builds from source are important concepts that will be supported. the minimum bits are, more will come [16:19] 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] i actually hope people do :) [16:20] it will prove the security setup [16:20] Maybe we should do a challenge to try and test the limity of snappy. [16:20] definitely ... and indeed file bugs for everything [16:22] The snappy challenge, who can get the most keyloggers to people :D Has UBuntu-Marketing an IRC channel? [16:22] well, keylogger and Xorg vulnerabilities would be a bit unfair until Mir is there [16:22] since it is a known open hole [16:22] okay, fair point [16:23] i'd start with a headless challenge ;) [16:27] Would In-App-Keyloggers be allowed? [16:28] why not [16:29] ok, maybe I find somebody in marketing that likes the idea :D [16:31] :) [17:01] niemeyer_, sorry I missed your ping earlier [17:32] 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:32] Launchpad bug 1577333 in squashfs-tools (Ubuntu) "snap-review failed with "checksums do not match"" [High,Confirmed] [17:33] jdstrand, how do the review tools check that ^^? Uncompress and recompress and compare checksums? [17:34] do you need to uncompress ? the sum should be in the meta data ... [17:34] so you just need to compare the squashfs sum vs meta [17:35] ogra_, ah, I didn't realize that. What would cause them not to match? [17:35] 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/ or would it be /org/freedesktop/dbus/properties with the destination com.ubuntu.location.service.? [17:35] recompressing them ?? [17:35] dunno [17:38] kyrofa: there are 3 bugs related to this that I'll be getting to after the interfaces, doc and devmode work [17:38] 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] slvn, ^^ FYI [17:39] 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] kyrofa: however, there are a couple of issues where timestamps are causing trouble, and perhaps something not timestamp related [17:40] no, snapcraft is fine [17:40] jdstrand, ah, I see, okay [17:40] it works a lot of the time but unfortunately it isn't 100% yet [17:42] kyrofa, I don't fully understand ... it seems to me *all* my packages systematically fails the checksum test. [17:43] slvn: you might be hitting one of the three different bugs [17:44] jdstrand, hmm ok! so all is under control :) [17:44] I'll be updating the review tools for something else, I should turn this check off until it is reliable [17:45] well, yes, though it'll still be a little while before it is fixed. but let me make it better for people [17:45] (ie, make the check temporarily non-fatal [17:45] ) [17:54] 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] jdstrand: ack - I hope we can get to those bugs soon and reenable the checks [17:58] me too :| [18:15] jdstrand, ack [18:29] 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] ssweeny: I was only saying that in general-- ie, whatever org.freedesktop.... accesses you might need to have Get and Set work [18:39] ssweeny: maybe that is nothing beyond what the dbus abstractions already give (I just didn't know) [18:39] ssweeny: (when location-control is standalone) [18:39] 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] ssweeny: oh no, we can't mediate on message contents, no [18:41] jdstrand, ok, thanks! [21:17] roadmr (cc beuno, nessita and tyhicks): can you pull r664 of the review tools for devmode support? [21:17] roadmr: and hi! :) [21:18] jdstrand: sure! I'll work on it, hello :) [21:18] roadmr: it can be next week if needed [21:18] roadmr: thanks :) [21:18] jdstrand: well it's fri evening so unless we escalate the hell out of it, it will be next week :( [21:18] jdstrand: I'll get the ball rolling though :) [21:19] hehe [21:20] roadmr: right, please don't escalate the hell out of it :) [21:20] hehe [21:20] \o/ thanks :) === JanC is now known as Guest59129 === JanC_ is now known as JanC === Kristbaum1 is now known as Kristbaum