=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:05] good morning [05:06] morning [05:13] hey zyga and mborzecki [05:13] Hey guys [05:47] * zyga has a doctor appointment on the other side of the city at 12:30, wondering if he should go now and wait there or wait and then go when it's hotter outside [05:50] mborzecki: can you look at 5254 please? :) [05:50] mvo: I sent the kernel RFC idea we talked about last night to 5260 [05:50] btw. i think we should merge #5258 [05:50] PR #5258: tests: fix lxd test which hangs on restore [05:50] +1 [05:52] mborzecki: 5257 is a short low hanging fruit in need of a 2nd review [05:53] zyga: ok === chihchun_afk is now known as chihchun [05:55] PR snapd#5258 closed: tests: fix lxd test which hangs on restore === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [06:16] zyga: 5257 is magic, had to go through snapstate for it to make sense :) [06:22] jdstrand: [06:23] mborzecki: thank you! it was sightly annoying because it poped up in the middle of something totally different [06:23] PR snapd#5257 closed: snapstate: ensure fakestore returns TypeOS for the core snap [06:23] mvo: hah, i can imagine it was tricky :) [06:24] zyga: can you take another look at #5256? [06:24] PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name [06:26] PR snapd#5261 closed: tests: wait more time until snap start to be downloaded on econnreset test [06:46] PR snapd#5241 closed: interfaces/udev: call 'udevadm settle --timeout=10' after triggering events [07:02] PR snapd#5255 closed: cmd/snap-confine: applied make fmt [07:05] mvo: can I merge https://github.com/snapcore/snapd/pull/5248#pullrequestreview-125842002 [07:05] PR #5248: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 [07:05] it is a 2.33 branch [07:05] with LXD test failing === pstolowski|afk is now known as pstolowski [07:06] morning [07:06] pstolowski: good morning [07:06] mvo: can you cherry-pick https://github.com/snapcore/snapd/commit/7f4d533166b73551317bf421bc88f65cfd6b12f9 to 2.33 ? [07:07] or let me open a PR with it [07:07] (that's the lxd bit) [07:07] mborzecki: if you open a PR please also cherry-pick the econnreset thing [07:08] mvo: ok [07:12] PR snapd#5262 opened: tests: backport lxd force stop and econnreset fixes (2.33) [07:12] mvo: zyga: ^^ [07:12] thanks [07:15] mborzecki: ta [07:46] jeez, got google:ubuntu-14.04-64:tests/main/econnreset failure this time; it seems to be flaky as well, i saw occasional failures before [07:47] pstolowski: master should have a workaround (timeout got increased) [07:47] mborzecki: hey, would you like to take another look at #5215 ? [07:47] mvo: ah, great, ty [07:48] PR #5215: ifacestate: improved conflict and error handling when creating autoconnect tasks [07:52] hello everybody [07:52] will firefox snap touch my existing firefox profile (ESR 52)? [07:53] Hey [07:54] I’m going offline for a few hours, at least till 14 [07:54] Ping me on irc if urgent [07:54] I have an older laptop without a modem with me [07:54] And I will be gardening my old branches [07:55] 5204 needs a review [07:55] it would unblock some more core18 work [08:19] mvo: left some comments in 5204 [08:20] pedronis: you're breaking my heart, can't use gorename for that Name() -> LocalName() job now :) [08:20] mborzecki: ? [08:21] pedronis: your comment about parallel installs and using a different name for the method to actually go through all the code locations where it's used at [08:21] pedronis: it's a valid concern btw [08:21] mborzecki: well, I'm trying to make suggestions not to break the software [08:22] I understand they are annoying, maybe [08:22] as I said, it's likely that you might learn that most places were fine [08:22] but is a bit unclear [08:24] yeah i tried to jot down some places where i'm certain we'll need the non-local name (eg. apparmor profiles, sice we'll hide the local name inside the mount ns) [08:33] pedronis: hey, about disconnect hooks, i think that if the snap on either end of connection is not active, we should either error out (but not with retry, it doesn't make much senso imho) or we should run the disconnect hook only on the active side and ignore the inactive one. both options are a little bit problematic though - we don't want to leak resources by not running a hook, but at the same time you may have good [08:33] reason to have snap disabled. and I don't think we want to block snap removal on not being able to run disconnect hook on the other end (because snap on the other end is not active) [08:34] pstolowski: mmh, we have static inactive and dynamic inactive though [08:34] pedronis: what do you mean, don't we have a single Active flag? [08:35] pstolowski: yes, but remember a refreshed snap is inactive for a while [08:35] and then gets back to active [08:35] that's why we have the complexity in autoconnect [08:38] pstolowski: afaik you need the same kind of code as autoconnect, but anyway all of this shows we really need to implement some of my recommendations or something similar. it's clear it's hard to keep in mind this stuff [08:38] yes [08:40] pedronis: btw I've read your recommendations twice last week, very well written, i've yet to read it once more [08:47] pstolowski: but yes, if the other side has no pending link* task and its inactive you have to skip its hooks [08:48] that's probably true for autoconnect as well (unless it's not listed anyway for other reasons) [09:16] pstolowski: as we discussed the behavior of disable and connections is probably a bit buggy already [09:25] yes [09:52] PR snapd#5263 opened: errtracker: do not send duplicated reports [10:13] how would root know what a user's XDG_CONFIG_HOME is? [10:23] Chipaca: in what context do you want to know? [10:23] Chipaca: inspect /proc/$pid/environ [10:23] Chipaca: of the user [10:23] mvo: daemon running as root needing to look at a user's config [10:23] Chipaca: but even then nfs-root-squash may squash us [10:24] Chipaca: maybe running a helper as this user? [10:24] :-( yeah [10:26] mvo: there might be a way to refactor things to take away the need, also [10:29] PR snapd#5215 closed: ifacestate: improved conflict and error handling when creating autoconnect tasks [10:29] PR snapd#5248 closed: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 [10:33] Chipaca: quick question about 5176 - this need to be reworked to just do a net.Dial() - is that correct? and also a new api command? [10:33] mvo: I understand that for some of them, yes [10:34] mvo: but not for all [10:34] mvo: the 'get the details and check the cdn' thing is still full http [10:34] so really just the auth check [10:34] Chipaca: ok [10:34] mvo: and one of the auth checks needs dropping entirely [10:35] Chipaca: do you have any thoughts about the API to use? apparently /v2/debug is out [10:35] mvo: we need to discuss, I think it could go in some for under system-info [10:35] inventing tons of new api is not sane either [10:35] I think [10:35] mvo: so... I'd either like to add a system-info command that better mapped /v2/system-info, with options of all sorts [10:35] mvo: or, maybe, have version grow options [10:35] Chipaca: yes, that was my proposoal [10:35] the second one feels weird [10:36] but didn't discuss it with Gustavo [10:36] is in a note in the PR [10:36] s/note/commnet/ [10:36] and then, whatever the command, i think a /v2/system-info option would be best for this and the verbose sandboxing thing [10:36] sandbox-features i mean [10:36] that one landed already though [10:37] but maybe it's in .33 ? [10:37] e.g. /v2/system-info?select=connectivity and /v2/system-info?select=sandbox-features [10:37] yep, landed, but could be hidden and deprecated [10:37] * pedronis needs to go have lunch [10:37] 2.33 is not released outside of beta yet so that should be fine [10:37] mvo: anyway we should have a chat at standup about this [10:38] pedronis: ok [10:43] * pedronis lunch is a bit delayed [10:44] mvo: btw discussing with Gustavo he also proposed that maybe we just continue to stick system config to "core" as key (even if it's not there), it might work, but it might mean disallowing config on any base until we have understand more/have a use case [10:46] pedronis: oh, interessting idea [10:47] pedronis: I was starting to look at the config once 5259 is ready (unless the concensus is that we should solve both in a single PR) [10:50] what would be the easiest way to stick custom snap-exec into core? bind mount my local copy over the real one? [10:50] mborzecki: for testing? yeah, bind mount sounds like the easiest option [10:50] mvo: yup for testing only [10:51] mborzecki: yeah, manual testing should be fine this way. alternative you can unpack the core snap and repack it [10:51] (but no need I think) [10:51] i actually make the tmpfs for /snap work somehow, snap-exec is the last bit standing in the way [11:13] ugh, unit test error on debian-9-64:tests/unit/go in master, on undo hooks test; i'm looking at it [11:23] PR snapd#5252 closed: store, jsonutil: move store.getStructFields to jsonutil.StructFields [11:35] PR snapd#5264 opened: many: use ~/.config/snap if it exists, instead of ~/.snap [11:36] law of preservation of the number of chipaca PRs [11:39] Chipaca: you should aim for 2, no more, no less, one big one small [11:39] your own rule of two [11:40] * Chipaca checks [11:40] yep, that's where I'm at [11:40] now if we all did this, we'd be *fine* [11:44] mborzecki: afair Gustavo explicitly said he expected to force the dir to always exist, not to use a tmpfs (that might be an issue on systems not having /snap though) [11:45] pedronis: the /snap/ dir? [11:45] yes [11:45] ack [11:52] * Chipaca lunches [12:10] mborzecki: hey, would you mind reviewing 5254? [12:16] fyi, my isp seems to be experiencing a major outage, even their own website is down and their phone is completely busy right now [12:20] pstolowski: orange? [12:21] zyga: awacom, a local provider [12:21] ah [12:21] wired network? [12:21] Yes [12:23] 5225 needs a second review, should be simple [12:27] * zyga looks [12:28] mvo: are we putting snapfuse on PATH? [12:29] zyga: yes and iirc we have to so that fuse finds it [12:30] mborzecki: The proposed constrains <- constraints [12:31] mborzecki: and I'd expect to be able to know the local key from inside the snap, as a debugging aid if nothing more [12:31] hm, i'll repeat this on the forum [12:31] * pstolowski back online [12:32] Chipaca: please do [12:32] PR snapd#5225 closed: selftest: add new selftest package that tests squashfs mounting [12:34] zyga: was 5225 a squash merge or a regular one? [12:34] pstolowski: https://github.com/snapcore/snapd/pull/5260/files needs a 2nd review and is pretty simple [12:34] mvo: I don't know, whatever was default on my system :/ [12:34] PR #5260: sefltest: advise reboot into 4.4 on trusty running 3.13 [12:34] probably regular [12:34] do you need a cherry pick ? [12:34] zyga: ok, I will do some cherry picks then [12:34] zyga: yeah, I want this for 2.33 as it may help with the protocol problem issues we see on errors.u.c [12:35] mvo: hold on, we can revert [12:35] and squash [12:35] shall I try? [12:35] zyga: its ok, its not that many commits [12:35] I'm sorry, I just read the diff and didn't noice the squash label [12:35] zyga: no worries [12:38] zyga: don't forget the 360 fun [12:39] Chipaca: already done it [12:39] oops [12:39] I will skip standup today [12:39] PR snapd#5265 opened: selftest: add new selftest package that tests squashfs mounting (2.33) [12:39] I actually should file the day as off as I wasn't of much use (doctor visit) [12:39] zyga: hmmm! [12:39] * Chipaca scribbles in his little black book [12:39] my daughter is returning from overnight school trip [12:39] and I need to pick her up in 20 minutes [12:39] mvo: hey! Hope that you don't mind that to save you some time after I review some smaller merges from you and approve, I'll also merge them? [12:40] sil2100: sounds great [12:40] mvo: also, my work hours will be a bit strange this week as my team is in Portland [12:40] sil2100: aha, right. the sprint [12:40] sil2100: have fun, I understand that you will be less available during the sprint [12:40] So I'm working in the morning and then to be with them on all the meetings I'm sticking around till after midnight [12:41] sil2100: Portland sounds just like Poland, there was a joke about that somewhere ;) [12:41] (since I stayed home) [12:41] sil2100: ok [12:41] zyga: almost like home! [12:42] Chipaca: some comments on 5264 [12:44] Chipaca: SNAP_HKEY_LOCAL_MACHINE and we're ready for being bought by MS [12:44] mborzecki: \o/ [12:44] :) [12:45] mborzecki: you will implement snapd active directory integration [12:45] and local group policy [12:45] * sil2100 AFK for a bit, will try to be back for standup [12:45] As part of that effort, I'll implement counting the dosh [12:45] dosh? [12:45] zyga: money [12:45] zyga: i can do the LDAP login bits, leave the rest for you :P [12:45] Chipaca: cash++ [12:45] nooooo! [12:46] * Son_Goku runs away from the insanity [12:46] * zyga observes Son_Goku run around in a room where all walls are plastered with big-brand company names [12:46] * Son_Goku runs screaming with his eyes bugging out [12:47] also we need to move from squashfs to that filesystem that was actually just ms's sql [12:47] * Son_Goku dies [12:47] Chipaca: the one that never made its way to windows? [12:48] WinFS [12:48] https://en.wikipedia.org/wiki/WinFS [12:48] DBaaFS [12:49] * zyga goes to pick up his daughter [12:49] mvo: I'm skipping standup, sorry [12:50] zyga: ok [12:50] zyga: (fun fact right next to ok (if you shift one row to the right): pl) [12:53] mvo: so you're saying pl is not ok because it's too far east [12:54] Chipaca: the opposite, its very ok, spelled ok one column on the keyboard to the east actually [12:54] mvo: if you want ok, but you're from the far right, you get pl [12:54] mvo: got it [13:24] PR snapd#5266 opened: interfaces/builtin/docker: use commonInterface over specific struct [13:31] PR snapd#5264 closed: many: use ~/.config/snap if it exists, instead of ~/.snap [13:40] PR snapd#5260 closed: sefltest: advise reboot into 4.4 on trusty running 3.13 [13:42] pstolowski: is this something you are looking into https://paste.ubuntu.com/p/qkNvVZcZZ6/ ? [13:42] mborzecki: yes! [13:42] ack [13:42] mborzecki: where do you see it? [13:43] pstolowski: saw it here https://github.com/snapcore/snapd/pull/5256 (restarted the build already) [13:43] PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name [13:43] mborzecki: debian or something else? [13:43] pstolowski: ubuntu-16.04-32 [13:44] https://github.com/snapcore/snapd/pull/5266 seems wrong to me, but I don't know enough to explain (or even count) the ways [13:44] PR #5266: interfaces/builtin/docker: use commonInterface over specific struct [13:44] mborzecki: ah, ok. that's good i guess [13:44] probably a zyga or jdstrand thing ^^ [13:46] * zyga looks [13:47] I had one question after continuing to read up on this, what interfaces need to be request for access to dotfiles in a user's home directory? [13:48] done [13:49] Trel: there's no generic interface for all of them [13:49] Trel: which dot files are you after, specifically? [13:51] https://github.com/snapcore/snapd/pull/5230 needs a second review [13:51] PR #5230: interfaces/udisks2: also implement implicit classic slot [13:51] In this case the ability to write new dotfiles to a user's home directory (or another they specify) as well as read ones that are already there, specifically .profile and .bashrc [13:52] maybe also .bash_profile [13:52] I saw "home" gives homedir access, but not to hidden files [13:52] Trel: there is no interface for that [13:52] because that is very dangerous [13:52] you can use it to essentially bypass confinement [13:52] why do you need to write to bash/sh profile files? [13:52] I'm assuming because of . and ..? [13:53] In this case, I was thinking of converting my new machine/account setup script(s) to a snap [13:54] Part of it is adding my standard dotfiles like .vimrc, adding to my PATH and adding some bits to .profile and .bashrc [13:54] because any interface that would allow this is pretty much equivalent to becoming unconfined it would not be something we hand out easily [13:54] I would instead suggest to rework the application to show how to add anything to one's profile scripts [13:55] part of the appeal of snaps is that they don't have real root/superpower over one's machine anymore [13:55] and we don't want to break the trust by creating an interface that can be easily abused [13:55] even if the intentions were pristine [13:56] I'm a confused about other than the .. directory entry, how accessing dotfiles in user's home is dangerous to anything other than the user [13:56] Or is that the reason why? [13:57] Trel: let me explain [13:57] Trel: if you can write to ~/.profile [13:57] then you can insert a payload that runs the next time a terminal is open [13:57] (or the next time any login shell starts) [13:57] that code is no longer confined so it could, for instance, wget a script from somewhere [13:57] and pipe it to sh [13:57] and that can do anything [13:57] so this is effectively a way to break out of the sandbox [13:58] Still restricted to that user's permissions though, right? That doesn't get you root access for example [13:58] no, but you can steal user's secrets, install malware, exploit a kernel issue to become root or anything else [13:58] (malware doesn't have to be root) [13:59] Yes, I meant full system compromise vs user compromise is all [13:59] I suppose I could have it generate a finalize script and drop it in their home that they'd have to run after manually. [14:00] In this case it's for my use primarily to expidite new setups, so I'd trust it since I wrote it. [14:00] right [14:00] well, you can always make a private devmode snap [14:01] but if you want to ship it to everyone you need to play by the sandbox rules [14:04] That's not something that'd be depreciated right? I have no problem using devmode for this since it's primarily personal. I'd distribute manually to anyone (non-me) who'd want it [14:04] sergiusens: I won't be around at that time today.. can we have it right now? [14:05] Otherwise it'll probably be too late for Evan [14:05] Trel: I don't think devmode for private snaps is something that is going to become deprecated [14:05] niemeyer: I set it for tomorrow, it is 7am for kyrofa_ right now [14:05] starting next week, it is on Tuesdays, [14:06] sergiusens: Ah, that works, thanks [14:06] does that work niemeyer or should I reschedule? [14:06] ah, great :-) [14:07] I had an issue yesterday with family and scheduling the meeting earlier flew by me, sorry for that [14:10] Then I guess that's fine for this one then. Most of the others I wanted to do are simple text transforms which I have to pipe text into, so I don't think those would need anything at all [14:10] I'm thinking of bundling a bunch of the text transforms into a single one and publishing that. [14:12] PR snapd#5262 closed: tests: backport lxd force stop and econnreset fixes (2.33) [14:16] mborzecki: thank you for the review [14:22] Chipaca: what's the progress on getting the snap command split out and ported over for us to use for `snap pack`? [14:31] * zyga -> lunch [14:35] sergiusens: "ported over"? [14:35] sergiusens: snap pack has had --check-skeleton for a while now (i thought you'd reviewed that?) [14:37] sergiusens: we haven't split it into its own .deb yet though [14:37] Chipaca: I had not reviewed AFAIK. We only discussed early March. "ported over", we currently support `snapcraft pack` on osx (and windows) [14:38] Chipaca: yeah, I cannot really use it until it is standalone [14:38] sergiusens: sorry, getting mixed messages [14:38] sergiusens: you wouldn't use the .deb on windows nor osx [14:38] sergiusens: so as far as those are concerned, it's unclear to me what you need [14:39] sergiusens: there are no code changes afaik to make it standalone, unless i'm misremembering [14:39] it's just packaging [14:39] Chipaca: let me state the requirement so I don't impose how you deliver it; I the `snap pack` to be runnable on Windows, OSX and Linux [14:39] sergiusens: ok. Done! [14:39] just tell me how to get it on each platform and we are good :-) [14:40] sergiusens: I don't have access to those platforms, but I assume you do. Do you have a go build env? [14:40] Chipaca: I did the changes as discussed in the standup to connectivity check, what about authConnCheck() - should this become a net.Dial() only check? if so I will delete a lot of code now [14:41] sergiusens: I seem to recall we explicitly agreed that we weren't on the hook for delivering binaries to windows and osx; if that's not correct, then we have a bunch of busywork to have that happen [14:42] sergiusens: so my question is, i think, how do you get the rest of the snapcraft build environ onto windows and osx [14:42] Chipaca: not immediately, no. I don't think it is as important now, but it would be a regression to not support it anymore [14:43] Chipaca: `brew install snapcraft` and on windows in a venv for now [14:43] brew install snapcraft is essentially a venv, just wrapped nicely into a higher order package manager [14:45] sergiusens: how does 'brew install snapcraft' or the venv pull in squashfs-tools? [14:45] Chipaca: https://formulae.brew.sh/formula/snapcraft [14:46] sergiusens: and that builds mksquashfs from source? [14:46] Chipaca: it is easy to create a formula for the snap command, I can scaffold it and get the first version if you promise to maintain it ;) [14:46] Chipaca: only on "upload", you would get it in what homebrew calls a "bottle" [14:46] sergiusens: if by "it" you mean the formula or whatnot, that's exactly what I'm trying to understand who owns it [14:46] which is like a wheel in python [14:47] Chipaca: https://github.com/Homebrew/homebrew-core/blob/master/Formula/snapcraft.rb [14:47] brew formulae are similar to rpm specs or Arch PKGBUILDs [14:47] Chipaca: did my earlier question get lost? or are you just busy? [14:47] main difference is that unlike the latter two, formulae are based on Ruby rather than shell [14:47] Chipaca: (busy is fine, just asking to ensure its not lost) [14:48] mvo: I'm trying to understand if we're on the hook for windows and osx binaries of snap and the surrounding build infra or not [14:49] I wouldn't even start to hazard a guess at how to integrate that with our CI [14:49] Chipaca: you are probably not [14:49] Chipaca: I own the snapcraft formula (maintain it), someone else the squash one. Once there is a snap command on homebrew I can replace the squashfs in "depends_on" to whatever the snap thing is called. [14:49] Chipaca: hm,hm,we will need a minimal snap pack in this case, we use too much syscall imports right now for GOOS=windows (but you know this already :) [14:49] Chipaca: alternatively, I can condition the code to just use the snap command on Linux and fallback to mksquashfs on other OS [14:50] sergiusens: it'd be simpler to just test for the /usr/bin/snap command, and if it doesn't exist, always fall back [14:50] Pharaoh_Atem: yeah, an actual call with parameter checks to be honest as the `snap` command namespace is quite busy ;-) [14:51] there is no `snap` formula yet at least [14:52] mvo: yes, authConnCheck should be a single net.Dial to the macaroon endpoint [14:54] sergiusens: do you know how to build things for osx and windows from travis? [14:56] * Chipaca googles [15:10] Chipaca: look at our .travis.yml and appveyor.yaml [15:11] PR snapd#5267 opened: tests: retry 'restarting into..' match in the snap-confine-from-core test [15:15] mvo: ping [15:16] sergiusens: ok, i'll take a stab at it [15:17] morphis: pon [15:17] morphis: h [15:17] morphis: pong [15:17] Chipaca: I updated the PR in question fwiw, but no rush [15:18] zyga: do you think you could look at 5204 again? [15:18] zyga: you asked for changes and I think I addressed things now [15:21] Chipaca: sure [15:21] * zyga looks [15:21] mvo: I tried to create a base snap recently and wanted to check if I was running into a bug or if what I was trying to do is simply not supported yet [15:22] mvo: basically I was setting `type: base` in my snap, build it and then installed it [15:22]