| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === JanC_ is now known as JanC | ||
| === Guest79971 is now known as ahasenack | ||
| === ahasenack is now known as Guest85272 | ||
| rvr | ogra_: Still no wifi on the Raspi 3 | 11:06 |
|---|---|---|
| === hikiko is now known as hikiko|ln | ||
| ogra_ | rvr, yes, likely a kernel issue | 11:30 |
| mup | Bug #1637981 opened: failed snap refresh removes security profiles <Snappy:New> <https://launchpad.net/bugs/1637981> | 11:44 |
| mup | PR snapd#2231 opened: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <https://github.com/snapcore/snapd/pull/2231> | 11:47 |
| bzoltan | elopio: I would need some help with the snapcraft tests | 11:53 |
| zyga | Pharaoh_Atem: hey, how are you? | 11:54 |
| Son_Goku | zyga: yo | 11:54 |
| Son_Goku | zyga: I just pushed a commit to (theoretically) grant homedir access: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/0e2c1fb73a520b348254142347bb7f4b8445b63a | 11:56 |
| === hikiko|ln is now known as hikiko | ||
| kalikiana_ | Hrm | 12:07 |
| kalikiana_ | Cannot allocate qemu:ubuntu-16.10-64: cannot launch qemu qemu:ubuntu-16.10-64: exec: "kvm": executable file not found in $PATH | 12:07 |
| kalikiana_ | Trying to run 'spread -v qemu' as suggested by HACKING.md | 12:08 |
| kalikiana_ | Tried to add a symlink in /snap but even that's not helping | 12:08 |
| kalikiana_ | It goes without saying I've installed what was asked for, and I do have a working kvm command on the host | 12:08 |
| kalikiana_ | Also: I do have the image in ~/snap/spread/23/.spread/qemu because I realized that's where spread is looking for it, even though it's not clearly stated and spread's readme actually talks about ~/.spread/qemu | 12:15 |
| sitter | We're having some problems with dbus confinement. KDE has lots of apps that (semi-implicitly; as in: devs might not even know dbus is involved) access the session bus and claim a service name on it. For all intents and purposes these are like dbus service-daemons with a well defined service name of the form org.kde.$appname. | 12:16 |
| sitter | This is how we implement unique application behavior (e.g. user starts foo, foo claims org.kde.foo, when foo is invoked again by whatever means it will first check if org.kde.foo is claimed and if so send a raiseWindow to that instead of starting a second instance of foo). | 12:16 |
| sitter | This also can be the case with multiple apps registering org.kde.$appname-* where * can be $pid or $pid-$randomstuff. | 12:16 |
| sitter | I am wondering if it would be possible to have a common interface which allows a snap to connect to the session bus and interact with a specific service name there (i.e. its own). | 12:16 |
| sitter | I did see a bus-name property in snapd's app validator, that doesn't seem to be supported as per snapcraft's validator though. | 12:16 |
| sitter | zyga, popey ^ | 12:16 |
| ogra_ | grrr, reconnect ... | 12:16 |
| ogra_ | kalikiana_, all necessary interfaces connected ? | 12:17 |
| kalikiana_ | ogra_: I have no idea. There's 0 information on what I might need :-) | 12:17 |
| sitter | popey: also, I just filed reservation requests for kcalc, kruler and ktuberling when you find a minute to approve them :) | 12:17 |
| ogra_ | kalikiana_, snap interfaces ... check if there are unconnected ones for the spread snap | 12:17 |
| kalikiana_ | ogra_: it has home,network,network-bind | 12:18 |
| ogra_ | well, was worth a try :) | 12:19 |
| kalikiana_ | it's also running in --devmode as per instructions, but I can't see that here | 12:19 |
| ogra_ | snap list should show that | 12:19 |
| kalikiana_ | Ah, it does indeed | 12:19 |
| popey | sitter: will do | 12:20 |
| kalikiana_ | ogra_: So you have the same ones? I feel I might be missing some kind of magic OR the snap itself has the wrong version - although it doesn't say anything about needing an edge channel version | 12:20 |
| Son_Goku | zyga, I wish snapd failed gracefully when it can't write files in protected places rather than hanging | 12:20 |
| ogra_ | kalikiana_, i never used spread before ... | 12:21 |
| kalikiana_ | Aha, okay. | 12:21 |
| ogra_ | seems edge and stable have th same revision though | 12:22 |
| kalikiana_ | I'd have to say I'm suspicious how it should be able to access "kvm" on my host, it'd be the first snap I see that can run anything from /usr/bin | 12:22 |
| kalikiana_ | And there's no such script inside it | 12:22 |
| ogra_ | well, --devmode should allow it to do anything it likes | 12:23 |
| ogra_ | (but spam your syslog like crazy) | 12:23 |
| Son_Goku | zyga, does snapd use FUSE for something? | 12:23 |
| kalikiana_ | Except accessing /usr/bin - even if it was in its PATH, it will see the core's /usr/bin | 12:23 |
| ogra_ | hmm, indeed | 12:24 |
| kalikiana_ | I don't see how that could ever work | 12:24 |
| kalikiana_ | So... there must be some other trick to it | 12:24 |
| bzoltan | ogra_: do you know who could be around this time who has some understanding of the snapcraft tests? | 12:24 |
| ogra_ | snap-confine does some bind mount magic here ... though i'm nmot sure how much of /usr/bin | 12:24 |
| ogra_ | bzoltan, fgimenez perhaps | 12:25 |
| bzoltan | ogra_: thanks | 12:25 |
| bzoltan | fgimenez: I would need some help with the snapcraft tests. How to run individual tests? | 12:25 |
| kalikiana_ | ogra_: I can see via snap run --shell that it's got a bunch of stuff but none of the qemu or kvm bits | 12:26 |
| kalikiana_ | (awesome command to have for debugging, sadly I'm still poking in the dark) | 12:26 |
| ogra_ | kalikiana_, i fear you need to wait for niemeyer | 12:29 |
| niemeyer | kalikiana_: If it is in --devmode, it should see the host filesystem in /var/lib/snapd/hostfs | 12:31 |
| niemeyer | kalikiana_: We're also working on a feature that will enable you to see that in / soon | 12:31 |
| kalikiana_ | Aha that's good to know | 12:36 |
| kalikiana_ | niemeyer: Would you know anything about using spread to run snapd tests? I can't get past 'Cannot allocate qemu:ubuntu-16.04-64: cannot launch qemu qemu:ubuntu-16.04-64: exec: "kvm": executable file not found in $PATH' | 12:37 |
| fgimenez | hey bzoltan, i don't know too much about snapcraft testing, probably elopio can explain accurately, but according to https://github.com/snapcore/snapcraft/blob/master/runtests.sh#L70 you can execute individual integration tests passing the name of the file, same goes for unit tests, hope this helps | 12:41 |
| bzoltan | fgimenez: thanks. i will check that out | 12:41 |
| mup | PR snapd#2232 opened: tests: add test for incorrect security files generation on undo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2232> | 12:41 |
| Son_Goku | niemeyer, does snapd have its own SSL cert loader? | 12:45 |
| niemeyer | Son_Goku: Hi | 12:46 |
| niemeyer | Son_Goku: What's the context? | 12:46 |
| zyga | Son_Goku: no, but it can control fuse through an interface somehow AFAIK | 12:46 |
| zyga | ogra_: what was the question about snap-confine? | 12:46 |
| Son_Goku | niemeyer, I'm writing the snapd selinux policy, and I got to the point where now it throws errors instead of hanging on enforcing... | 12:47 |
| Son_Goku | this is what I get: https://paste.fedoraproject.org/466809/47791801/ | 12:47 |
| kalikiana_ | fgimenez: Any idea on the 'kvm: executable not found' error? I'm out of ideas on how to run the spread tests | 12:49 |
| mup | PR snapd#2231 closed: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2231> | 12:52 |
| Son_Goku | niemeyer, why does snapd download the /tmp instead of downloading to /var/lib/snapd/snaps? | 12:58 |
| === fginther` is now known as fginther | ||
| niemeyer | Son_Goku: Hmm.. the former issue looks like snapd cannot open the local certificate on the host system | 13:03 |
| Son_Goku | yeah, I fixed that | 13:03 |
| niemeyer | Son_Goku: Ah, ok.. after you asked the previous question (SSL cert loader), or was that a different question? | 13:04 |
| Son_Goku | after I asked the SSL question, I pretty much guessed it does its own HTTPS stuff | 13:04 |
| Son_Goku | so I added rules for it: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/3b7e03c4428f8908e1d21a22cea9a78b522694fe | 13:04 |
| Son_Goku | niemeyer, now I want to know why snapd downloads snaps to /tmp instead of /var/lib/snapd/snaps | 13:05 |
| Son_Goku | it doesn't make much sense to me | 13:05 |
| niemeyer | Son_Goku: Yeah, it can talk to remote systems using TLS so it needs a proper db of certs indeed | 13:05 |
| niemeyer | Son_Goku: Yeah, we've fixed that already | 13:05 |
| niemeyer | Son_Goku: 2.17 will have that corrected | 13:06 |
| Son_Goku | ah, so it doesn't do this anymore, good | 13:06 |
| Son_Goku | because I wasn't sure how to handle the context transition case when files get moved around | 13:06 |
| Son_Goku | from /tmp to /var/lib/snapd | 13:06 |
| niemeyer | Son_Goku: Yeah, 2.17 will write .partial files on a download directory and then rename them in place, which is much nicer for multiple reasons | 13:07 |
| Son_Goku | yep | 13:07 |
| Son_Goku | and it neatly solves an selinux problem I wasn't sure how to solve | 13:07 |
| Son_Goku | and the practical problem of systems having ramdisk /tmp run out of space | 13:08 |
| Son_Goku | niemeyer, the download directory is in /var/lib/snapd? | 13:08 |
| Son_Goku | as long as it's in there, I don't need to do anything to handle it | 13:09 |
| ogra_ | zyga, already answered (/var/lib/snapd/hostfs) | 13:14 |
| zyga | ogra_: ah, thanks | 13:23 |
| Son_Goku | zyga, why does snapd need to read the dbus config dir? | 13:23 |
| lorenzo__ | Hello | 13:27 |
| lorenzo__ | Quick question, does anyone know how to install snapd on CentOS? | 13:28 |
| zyga | Son_Goku: it needs to read it to remove stale files it creates | 13:34 |
| zyga | Son_Goku: in all those cases it manages a subset of "snap-*" | 13:34 |
| niemeyer | Son_Goku: Yes, it will be in there for sure | 13:34 |
| Son_Goku | zyga: so it needs read/write access there | 13:35 |
| niemeyer | Son_Goku: Not sure if under .../partial or .../snaps yet.. we're likely touching this today/tomorrow for making it nicer | 13:35 |
| Son_Goku | niemeyer, as long as it's in /var/lib/snapd, I don't care :) | 13:35 |
| niemeyer | Son_Goku: So you're good :) | 13:36 |
| Son_Goku | niemeyer, I'd probably suggest /partial or /snaps/partial | 13:36 |
| Son_Goku | the latter is more intuitive | 13:36 |
| niemeyer | Son_Goku: That's what we have in master, but it creates some non-obvious consequences | 13:36 |
| Son_Goku | oh? | 13:36 |
| niemeyer | Son_Goku: e.g. on "snap download foo", we want foo.snap.partial in $CWD | 13:36 |
| niemeyer | Son_Goku: We're still figuring the details, but we want to make sure the same code path works nicely both on snapd and on snap download, etc | 13:37 |
| Son_Goku | snap download doesn't use snapd? | 13:38 |
| niemeyer | Son_Goku: It does, but not for everything.. we don't want plain users fiddling with content that goes into sensitive directories | 13:40 |
| niemeyer | Son_Goku: IOW, anyone in the system can do "snap download".. only root can put content into snapd/... | 13:41 |
| Son_Goku | niemeyer, what does snapd depend on fusedevice for? | 13:47 |
| mhall119 | sitter: I've approved your app name registrations | 14:20 |
| bzoltan | elopio: ping | 14:21 |
| elopio | bzoltan: pong | 14:23 |
| bzoltan | elopio: yo man :) I need some help with snapcraft plugin/tests | 14:24 |
| elopio | bzoltan: sure. Unit or integration? | 14:24 |
| bzoltan | elopio: whatever needed. I guess unit | 14:24 |
| elopio | bzoltan: well, if you are adding a plugin you need the two types :) I first need to take a look at the ones from Pharaoh_Atem, and then I have all the time for you. How can I help you? | 14:25 |
| elopio | pitti: ping. Any idea about "No annotated tags can describe 'cdefe0fc2dda29b4290eb4a054dbe607b61da21b'."? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-elopio-snapcraft-semaphore/xenial/amd64/s/snapcraft/20161028_194936_f7252@/log.gz | 14:25 |
| bzoltan | elopio: I made a simple plugin what zips up the staging space after build. This is for development use. For example when we build the qt-ubuntu content interface we will need a tar.gz with the .h and .so files. Like -dev package in deb world. | 14:26 |
| bzoltan | elopio: the plugin is ready (super simple) and I want to make nice tests for it... I am not familiar with the test framework of the snapcraft. | 14:27 |
| elopio | bzoltan: we have unit tests for full line coverage, and integration tests where you call the snapcraft command in a real snapcraft.yaml | 14:30 |
| kalikiana_ | balloons: Did you have a chance to check out the lxd-client interface? | 14:31 |
| elopio | bzoltan: your plugin sounds really similar to dump, so you can probably start copying the initial tests from snapcraft/tests/test_plugin_dump.py | 14:31 |
| elopio | and integration_tests/test_dump_plugin.py | 14:31 |
| elopio | I see a naming inconsistency there :/ | 14:32 |
| ogra_ | mvo, ! | 14:33 |
| mvo | hey ogra_ | 14:33 |
| ogra_ | mvo, do you mind if we kill the arch: all pi3 gadget in the store (seems there was an old one that used to be arch: all, not armhf ... people can actually download it on x86 machines) | 14:34 |
| mvo | ogra_: sure, lets do that | 14:34 |
| bzoltan | elopio: the problem is that the dump is done before the build... my plugin needs a built snapcraft project. | 14:34 |
| * ogra_ goes ahead | 14:34 | |
| mvo | ogra_: aynthing new on the pi3 wifi issue? if not I will try to get pitti to have a look at it too | 14:34 |
| ogra_ | mvo, i suspect there is also a relared kernel issue here ... sadly ppisati fried his pi3 during the sprint :( | 14:35 |
| ogra_ | (and now he is on vacation) | 14:35 |
| ogra_ | mvo, but having pitti aboard might help (if there is no bank holiday for him today (reformationstag)) | 14:36 |
| ogra_ | bah ... so i cant just uncheck all channels for pi3 rev2 | 14:36 |
| elopio | bzoltan: I thought your plugin would be dump + zip. Do you need it as a post-step for all the existing plugins? | 14:37 |
| ogra_ | but at least i can unpublish | 14:37 |
| ogra_ | sigh | 14:37 |
| bzoltan | elopio: it is just a zip | 14:37 |
| ogra_ | and the store automatically went back to publish rev1 instead | 14:38 |
| * ogra_ unpublishes that too | 14:38 | |
| ogra_ | ok, thats better, only rev6 now ... and armhf only | 14:38 |
| bzoltan | elopio: it will look like this: http://pastebin.ubuntu.com/23407202/ and the project produces the qt-ubuntu.snap and the qt-ubuntu-api.tar.gz files | 14:41 |
| elopio | bzoltan: to me, that sounds like a new step in the lifecycle, probably handled with a new attribute in the yaml. But Sergio and kyrofa are the ones that decide about that kind of design. | 14:43 |
| elopio | Sergio is in a sprint. You can find him in rocket or telegram. | 14:44 |
| bzoltan | elopio: well... i am doing the plugin and will offer to upstream :) But my problem is that I do not understand the unit test structure | 14:46 |
| sitter | mhall119: thanks | 14:46 |
| elopio | bzoltan: put a simplified version of your paste into integration_tests/snaps, and in integration_tests/test_development_plugin.py write a test that calls snapcraft and checks that it creates the zip file. | 14:50 |
| bzoltan | elopio: ok, that is the integration test part. That sounds doable. What about the unit test? | 14:52 |
| elopio | bzoltan: on the unit tests, it really depends on the code you write. I imagine a test like this one: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_plugin_dump.py#L42 but called something like test_build_creates_zip | 14:55 |
| bzoltan | elopio: Okey, thanks. I will pull together something and we'll see if it does the job. | 14:56 |
| bzoltan | elopio: my problem with the unit test is that I do not know how to create a stage space from a template yaml | 14:56 |
| bzoltan | elopio: the integration test you suggest will do the trick... | 14:57 |
| elopio | but I'm confused about your code. I'm not really sure how you would enforce that there are contentes in stage, or how to make sure that it's the last to run. | 14:57 |
| elopio | bzoltan: but if you want, push the code to a PR, and comment on it that's work in progress. It will make the discussion easier. | 14:57 |
| elopio | bzoltan: in unit tests, you don't always need a yaml. You just mkdir stage, and put some files in there. | 14:58 |
| bzoltan | elopio: ahh... mkdir and file creation... cool | 15:00 |
| balloons | kalikiana_, is the interface ready? | 15:01 |
| balloons | kalikiana_, I can definitely try it out if it's ready | 15:01 |
| kalikiana_ | balloons: It's in the branch, https://github.com/snapcore/snapd/pull/2225 | 15:03 |
| mup | PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225> | 15:03 |
| balloons | kalikiana_, awesome. I've got release work to do today and tomorrow, but I will definitely try it this week. If you want to vet it out yourself, feel free to try adding it to juju and building a snap: https://github.com/juju/juju/blob/staging/snapcraft.yaml | 15:05 |
| sitter | mhall119: something that puzzles me about the store. I upload something -> it gets auto rejected on account of being crap quality -> I upload a new revision with fix -> new revision is now queued for automatic checks saying "Revision waiting for review of a previous upload." and that previous upload is in status "Manual review pending". is that intentional? | 15:06 |
| sitter | because that is fairly screwing with my productivity just now :/ | 15:06 |
| mhall119 | nessita: ^^ can you answer that? It sounds like a bug in the workflow to me | 15:26 |
| kalikiana_ | stgraber, jdstrand: wrt lxd-client being all-powerful, is that a shortcoming in apparmor/seccomp? or the lxd API being unrestricted? | 16:26 |
| kalikiana_ | Wondering where to take that discussion, presuming the current unconfined state is temporary | 16:27 |
| === JanC_ is now known as JanC | ||
| stgraber | kalikiana_: nothing to do with apparmor/seccomp limitations, it's just that LXD has legitimate use for all of that access | 17:21 |
| stgraber | kalikiana_: the LXD API lets you define containers that have raw access to disks, PCI devices, USB devices, specific kernel modules and intefrace, ... | 17:21 |
| stgraber | and things like Juju actually use that to pass through access to openvswitch for OpenStack or even /dev/mem in some cases | 17:21 |
| stgraber | kalikiana_: we may at some point add the concept of tenants to LXD and could then in theory have security profiles or something to restrict what those tenants can pass to containers and then build a snapd interface on top of that to allow for auto-connect to lxd. But that's not on our roadmap for this cycle nor even for the next one, so right now, the LXD API is very much privileged and can't be given to | 17:24 |
| stgraber | any random user/snap. | 17:24 |
| Sweet5hark | "cannot bind mount nvidia driver /usr/lib/nvidia-340 -> /tmp/snap.rootfs_OKbiYH/var/lib/snapd/lib/gl. errmsg: No such file or directory" <- anyone has an idea what that is? | 17:27 |
| ogra_ | Sweet5hark, some leftover nvidia driver cruft ? | 17:29 |
| ogra_ | does /usr/lib/nvidia-340 exist and does it have the GL libs inside ? | 17:30 |
| Sweet5hark | ogra_: yes and yes | 17:30 |
| ogra_ | any other nvidia-* dirs in /usr/lib ? | 17:31 |
| Sweet5hark | FWIW, /tmp/snap.rootfs_OKbiYH/ exists, is owned by root:bjoern and is empty -- the paths below it do not exist. | 17:33 |
| Sweet5hark | Also for context: I tried to install libreoffice from edge, aborted the dl, which FUBARed snap state. Thus I ran https://raw.githubusercontent.com/zyga/devtools/master/reset-state -- retried, it installed fine, but doesnt start because of the above .... | 17:35 |
| Sweet5hark | ogra_: There is nvidia-340 and nvidia-340-prime in /usr/lib | 17:36 |
| ogra_ | the message comes from inside the core snap, i dont think you can see anything when looking from the outside | 17:36 |
| ogra_ | probably it chokes on -prime ... | 17:37 |
| ogra_ | zyga, ^^ any known remaining bugs with snap-confine and nvidia ? | 17:37 |
| === Guest85272 is now known as ahasenack | ||
| === ahasenack is now known as Guest84237 | ||
| kyrofa | Isn't the core snap supposed to handle GL access? | 17:59 |
| kyrofa | ogra_, do you know anything about that? I have an app dying because it can't access libGL.so.1 | 18:12 |
| ogra_ | nop | 18:12 |
| ogra_ | e | 18:12 |
| ogra_ | it isnt so much the core snap, rather snap-confine that bind mounts the libGL stuff from the host into the core snap and provides the gl interface | 18:13 |
| cwayne | kyrofa: ISTR having to have something like this in my wrapper script: export LIBGL_DRIVERS_PATH=$SNAP/usr/lib/$ARCH/dri | 18:15 |
| kyrofa | Huh... I just ran `snap run --shell` and it's not in there anywhere, so it must not be bind-mounted in. zyga, any ideas? | 18:18 |
| kyrofa | Oh my. I completely missed that opengl was an interface now | 18:25 |
| kyrofa | I'm sure that's it | 18:25 |
| kyrofa | Nope, nevermind. Changes nothing | 18:29 |
| kyrofa | Looking at the interface, looks like something should be contained within /var/lib/snapd/lib/gl, but it's not | 18:32 |
| ogra_ | kyrofa, well, snap-confine should mount your hosts GL libs there | 18:45 |
| kyrofa | ogra_, yeah, that doesn't seem to be working | 18:45 |
| ogra_ | (on demand i think) | 18:46 |
| kyrofa | Man it's quiet around here | 20:07 |
| femme | Did a snappy security audit happen (yet)? | 20:46 |
| femme | We're considering using snaps for tor as distros tend to not update after a while and so I just joined to get caught up on the snap ongoings and discussions and maybe someone would like to help | 20:50 |
| qengho | femme: Hi hi. I can't answer about an audit, but I would like to be a bridge between Tor and snappy communities. I think it's a great fit. I made the tor-middle-relay snap, and am on the OFTC channel too. | 20:54 |
| qengho | femme: I would love to contribute what I know to make snaps a side-effect of building the official builds for deb packages. | 20:55 |
| femme | qengho: great, I didn't know there was a middle relay snap | 20:56 |
| * qengho moves to that dev channel. | 20:58 | |
| kyrofa | femme, I'll point you to the security team -> tyhicks? | 21:16 |
| kyrofa | femme, qengho please let me know if you run into difficulties from a packaging perspective | 21:19 |
| tyhicks | femme: hey - there's not been an independent security audit of snappy as a whole but the Ubuntu security team is active in the development of snappy | 21:19 |
| tyhicks | femme: for example, we review all that changes that go into the snap launcher (snap-confine) and we also review and/or author the changes to the interfaces (security policy) | 21:21 |
| zyga | tyhicks, femme: suse security team did review snappy security | 21:27 |
| zyga | and found a few issues that were since fixed | 21:28 |
| zyga | you can count that as indepdentend security review i think | 21:28 |
| tyhicks | oh, good point | 21:28 |
| zyga | kyrofa: it's been a long day :) | 21:28 |
| tyhicks | I had forgotten about that | 21:28 |
| kyrofa | zyga, yeah I bet! How's the sprint? | 21:28 |
| zyga | kyrofa: hey, so wha'ts about nvidia that you have issues with? | 21:28 |
| zyga | kyrofa: and which distro are we talking about as each one is different | 21:29 |
| kyrofa | zyga, I've got an app that wants libGL.so.1, and it's not finding it. Neither am I, using snap run --shell | 21:29 |
| zyga | kyrofa: sprint is tense :) we're working on the release again | 21:29 |
| kyrofa | zyga, classic | 21:29 |
| zyga | libGL.so.1 you say? | 21:29 |
| kyrofa | Yep | 21:29 |
| femme | tyhicks: thanks for the response, so I'm having a glance and the parts wiki page jumps out at me. It seems more complicated than it has to be when a (signed) repo would have been better. | 21:30 |
| femme | zyga: great to hear | 21:30 |
| zyga | kyrofa: do you see it in /usr/lib/nvidia-/ anywhere? | 21:30 |
| femme | would love to read a writeup if there was one | 21:30 |
| zyga | femme: signed repo of what? | 21:30 |
| femme | https://wiki.ubuntu.com/snapcraft/parts | 21:31 |
| kyrofa | zyga, indeed, both /usr/lib/nvidia-340/libGL.so.1 and /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 | 21:31 |
| zyga | femme: you do relise the whole idea is that that we don't review actual code, just the sandbox | 21:31 |
| kyrofa | femme, those are just build-time parts for users to utilize when building snaps. It has nothing to do with snapd itself | 21:31 |
| zyga | kyrofa: the latter is not something we handle, the former, hmm, is this a hybrid system? | 21:31 |
| femme | I know | 21:31 |
| zyga | kyrofa: can you do snap-confine --version by any chance (or just tell me the version from dpkg) | 21:32 |
| kyrofa | zyga, yes, it's one of those monstrosities. Never do it! | 21:32 |
| zyga | s/relise/realise/ | 21:32 |
| kyrofa | zyga, 1.0.43-0ubuntu1~16.04.1 | 21:32 |
| zyga | kyrofa: is it a hybrid system? | 21:32 |
| kyrofa | zyga, yes | 21:32 |
| zyga | kyrofa: if it is, then what you may be observing is that a) we have a bug (maybe) b) nvidia driver is not really loaded yet | 21:33 |
| kyrofa | zyga, indeed, the nvidia driver isn't loaded | 21:33 |
| zyga | kyrofa: please collect as much data as you can and report a new bug | 21:33 |
| kyrofa | zyga, well, I'm using the intel side | 21:33 |
| zyga | kyrofa: for hybrid systmes I bet we need more smarts | 21:33 |
| kyrofa | zyga, but I shouldn't HAVE to be using nvidia... | 21:33 |
| femme | I realize it's not directly snapd related but it's a single point of failure for those using the parts, which seems to be recommended | 21:33 |
| kyrofa | femme, no need to use them, they just help sometimes when snapping things | 21:34 |
| zyga | kyrofa: I agree, I just need data to know how to fix it | 21:34 |
| kyrofa | zyga, sounds good, happy to help | 21:34 |
| zyga | femme: snaps should be okay to use even if you use none of the shared parts | 21:34 |
| kyrofa | Even the shared parts get confined the same if used | 21:35 |
| zyga | kyrofa: look at /sys/module/nvidia/version | 21:35 |
| zyga | kyrofa: do you have it? | 21:35 |
| zyga | kyrofa: and if so, what's in it? | 21:35 |
| kyrofa | zyga, it seems I don't have it when using intel | 21:35 |
| zyga | kyrofa: right, then what I think is happening is that the app expects a particular GL.so but the snap is not providing it | 21:36 |
| zyga | kyrofa: typically snaps seem to bundle all FOSS userspace side drivers | 21:36 |
| nacc | femme: i think what you're referring to is that if the shared parts were to change/break in some way, there's not really a way to fix it in your current build; but that only matters for building a new version, the existing snaps don't depend on the parts any longer (the shared parts were integrated during the build, aiui) | 21:36 |
| zyga | kyrofa: maybe that's just missing | 21:36 |
| femme | With the whole Startcom thing and whoever else has access to SSL CA certs I wouldn't want to wait until something goes wrong to say "you could have not used it" | 21:36 |
| kyrofa | nacc, you understand correctly | 21:36 |
| nacc | kyrofa: thanks | 21:37 |
| zyga | kyrofa: I need to sleep, please report a new bug and let's work together on solving this | 21:37 |
| femme | nacc: yes, which makes the developer a target | 21:37 |
| zyga | kyrofa: I'm so sleepy now, sorry | 21:37 |
| kyrofa | zyga, yeah, go away, I'm sorry I pinged you, I forgot about the sprint ;) | 21:37 |
| zyga | kyrofa: no worries, it' the (wink wink) last one this year | 21:37 |
| kyrofa | zyga, ha! | 21:37 |
| zyga | (conditions apply, your mileage may vary) | 21:38 |
| nacc | femme: depends on how you mean that -- the developer is expressing a dependency by relying on the external code (which is really what the shared part is); so yes, the developer is a 'target' if that external code breaks | 21:38 |
| kyrofa | femme, that's an argument against any dependencies | 21:38 |
| femme | It's an argument against not checking the integrity of dependencies, aka relying on https as your only line of defense | 21:39 |
| nacc | femme: so are you arguing purely against how the shared parts are currently distributed? | 21:40 |
| femme | if the developer's connection is mitm'ed by someone who can issue valid wiki.ubuntu.com ssl certs they can put whatever they want on that parts page | 21:40 |
| femme | and it gets built into the binary and distributed to everyone | 21:41 |
| kyrofa | femme, if an attacker has that power I feel like that's the least of the dev's worries | 21:42 |
| zyga | femme: isn't that true in general | 21:42 |
| zyga | femme: your ubuntu.iso was fetched over https | 21:42 |
| zyga | femme: and we can do better but at some point you have to have some way to bootstrap trust | 21:43 |
| femme | kyrofa: that's a step above what the ubuntu security team said when I told them years ago that they should have ssl certs on ubuntu.com but they closed the ticket as WONTFIX | 21:43 |
| zyga | femme: remember that when this happes, the most you can exploit is what that single snap could do | 21:43 |
| femme | but hey, they turned around on that too, only took them a few years. | 21:43 |
| kyrofa | femme, even if we could integrity check the contents of the wiki, it's just a dict pointing elsewhere. The code comes from github etc | 21:44 |
| nacc | iirc, the ubuntu isos are actually served over http; the md5sums are served over https. We just had this argument a few days ago on #ubuntu. :) | 21:45 |
| kyrofa | femme, if an attacker can impersonate https-protected websites they can just impersonate that one | 21:45 |
| femme | kyrofa: that would've been the next point, there should be some signing mechanism implemented | 21:46 |
| nacc | if all https sites are compromised (potentially), it does feel like there is a large issue at hand | 21:46 |
| kyrofa | nacc, exactly | 21:46 |
| femme | if all https sites are compromised I'm fine because I'm using tor | 21:46 |
| kyrofa | femme, how do you check a svn repo? Or git? | 21:46 |
| femme | A few measures I would take are: 1) enable and test key pinning with wiki.ubuntu.com's key in snapd 2) have every snap developer keep a key with which they sign the tar of the sources and include the md5 of it in the yaml | 21:55 |
| femme | s/md5/sha256/ | 21:55 |
| kyrofa | femme, they aren't necessarily tarballs, that's my point | 21:55 |
| femme | kyrofa: they can be tarred on the developers machine | 21:56 |
| kyrofa | femme, how are they verified then if the build recipe itself pulls from git? | 21:57 |
| femme | https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility#Securing_Updates | 21:59 |
| femme | kyrofa: they are made by ubuntu they can just be signed by a key already trusted | 22:01 |
| kyrofa | What are made by ubuntu? How is the signature of the tarball verified if the tarball isn't downloaded? | 22:02 |
| femme | if the tarball isn't downloaded what is the dev planning on building the sources with? | 22:03 |
| kyrofa | femme, git cloned sources. Or svn. Or hg. Or any of the myriad of source types supported by snapcraft | 22:03 |
| femme | kyrofa: which can be tarred? | 22:03 |
| femme | the tarring bit is just a technicality | 22:04 |
| kyrofa | femme, so your recommendation is to get rid of all source types except tarballs? | 22:04 |
| femme | no | 22:04 |
| femme | I'm kinda done with this conversation for now | 22:06 |
| femme | I'll gladly write a report if someone pays me ;) | 22:06 |
| mup | PR snapd#2233 opened: docs: update the name of the command for the cross-build <Created by elopio> <https://github.com/snapcore/snapd/pull/2233> | 22:07 |
| kyrofa | Alright, have a nice day femme | 22:08 |
| femme | (speaking of keys already trusted by ubuntu, it's kinda scary with two keys from 2004 still there) | 22:09 |
| femme | kyrofa: the idea is that the sha256 of every source is included (and if it's not a single file, tar them and sha256) and that it's signed by the developers private key (the public part which is also included) | 22:36 |
| femme | It could be implemented for parts which was my main example but I don't know much about the key infrastructure of ubuntu and if it would make sense to suggest for example pinning the key for parts in snapd alongside the pinning of the ssl cert of the URL, because if both keys are kept at the same place it doesn't matter but otherwise it is an improvement | 22:38 |
| femme | And it would use trust-on-first-use on a per snap basis for other keys | 22:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!