| 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 | 00:52 |
|---|---|---|
| nhaines | ls | 03:26 |
| zyga | o/ | 06:33 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| shuduo | ogra_: hello, may i know where is official kernel repo for rpi2 snappy image? | 07:55 |
| 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:37 |
| shuduo | ppisati: ping | 08:46 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| ppisati | shuduo: pong | 10:37 |
| shuduo | ppisati: may i know what kernel tree and branch is being used for snappy on raspberry pi 2? | 11:17 |
| 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 | 11:37 |
| === chihchun is now known as chihchun_afk | ||
| kyrofa | Good morning | 12:07 |
| qengho | jdstrand: what does the "unconfined" security plug look like these days? Still old-security? | 12:10 |
| === Guest24582 is now known as devil_ | ||
| jdstrand | qengho: it looks like --devmode :) | 12:40 |
| 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:41 |
| ppisati | shuduo: that's my personal git tree | 12:45 |
| ppisati | shuduo: use this: | 12:46 |
| ppisati | shuduo: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=raspi2 | 12:46 |
| shuduo | ppisati: got it. thanks. | 12:59 |
| 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:38 |
| niemeyer_ | ssweeny: ping | 13:40 |
| jdstrand | morphis: nice! :) | 13:42 |
| 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:44 |
| * jdstrand nods | 13:45 | |
| 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:37 |
| ogra_ | file a bug ... i guess that needs some discussion | 14:39 |
| 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:40 |
| Kristbaum | Can I also file a bug, concerning the "repoducable Builds" thing, or would this be more anoying, than helpful? | 14:58 |
| kyrofa | Kristbaum, are you talking about bug #1582417 | 15:01 |
| ubottu | bug 1582417 in Snapcraft "snapcraft doesn't create binary-identical reproducible builds" [Undecided,New] https://launchpad.net/bugs/1582417 | 15:01 |
| 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:05 |
| kyrofa | Kristbaum, not that I know of | 15:10 |
| 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:12 |
| 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:14 |
| ogra_ | snaps really only care about binary ... | 15:15 |
| ogra_ | everything else would be added meta data for the store side | 15:15 |
| 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:16 |
| 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:21 |
| ogra_ | you dont | 15:29 |
| ogra_ | (afaik that telegram app is actually the binary from telegram.org ...) | 15:32 |
| 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:33 |
| 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:34 |
| ogra_ | what it enforces is the security model ... no app should be able to access any data or service you havent explicitly authorized | 15:35 |
| 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:37 |
| 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:39 |
| ogra_ | be it disk, network, sensors on your phone or whatever | 15:40 |
| 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:41 |
| ogra_ | you can if the developer tells you how it was built and points you to the source code | 15:42 |
| ogra_ | if you are concerned about that you will have to check the details of the respective snaps you use | 15:43 |
| 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:44 |
| 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:47 |
| ogra_ | well, the hope is indeed that telegram uses a snapcraft.yaml in its tree and simply provides an official snap | 15:48 |
| 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:54 |
| ogra_ | thats called launchpad ;) | 15:55 |
| ogra_ | (such an LP feature exists already) | 15:55 |
| ogra_ | but still, it is optional | 15:55 |
| 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:56 |
| 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:57 |
| * ogra_ hasnt had issues yet | 15:58 | |
| ogra_ | Kristbaum, well, ask sergiusens :) | 15:58 |
| ogra_ | if he feels like updating | 15:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| jdstrand | reproducible builds and builds from source are important concepts that will be supported. the minimum bits are, more will come | 16:17 |
| 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:19 |
| 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:20 |
| 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:22 |
| ogra_ | i'd start with a headless challenge ;) | 16:23 |
| Kristbaum | Would In-App-Keyloggers be allowed? | 16:27 |
| ogra_ | why not | 16:28 |
| Kristbaum | ok, maybe I find somebody in marketing that likes the idea :D | 16:29 |
| ogra_ | :) | 16:31 |
| ssweeny | niemeyer_, sorry I missed your ping earlier | 17:01 |
| 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:32 |
| ubottu | Launchpad bug 1577333 in squashfs-tools (Ubuntu) "snap-review failed with "checksums do not match"" [High,Confirmed] | 17:32 |
| kyrofa | jdstrand, how do the review tools check that ^^? Uncompress and recompress and compare checksums? | 17:33 |
| 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:34 |
| 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:35 |
| 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:38 |
| 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:39 |
| 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:40 |
| slvn | kyrofa, I don't fully understand ... it seems to me *all* my packages systematically fails the checksum test. | 17:42 |
| jdstrand | slvn: you might be hitting one of the three different bugs | 17:43 |
| 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:44 |
| 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:45 |
| 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:54 |
| tyhicks | jdstrand: ack - I hope we can get to those bugs soon and reenable the checks | 17:58 |
| jdstrand | me too :| | 17:58 |
| beuno | jdstrand, ack | 18:15 |
| 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:29 |
| 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:39 |
| jdstrand | ssweeny: oh no, we can't mediate on message contents, no | 18:40 |
| ssweeny | jdstrand, ok, thanks! | 18:41 |
| 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:17 |
| 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:18 |
| jdstrand | hehe | 21:19 |
| jdstrand | roadmr: right, please don't escalate the hell out of it :) | 21:20 |
| jdstrand | hehe | 21:20 |
| roadmr | \o/ thanks :) | 21:20 |
| === JanC is now known as Guest59129 | ||
| === JanC_ is now known as JanC | ||
| === Kristbaum1 is now known as Kristbaum | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!