=== chihchun_afk is now known as chihchun
zygaHey :-)05:25
mborzeckizyga: hey hey05:32
=== chihchun is now known as chihchun_afk
zygaHey mvo :-)06:09
mvohey zyga06:09
mvoit looks like we have failures in the testsuite in fedora / centos right now06:09
mvoor is it just my PR?06:09
zygaMy stuff was ok last night06:10
zygaI’m getting breakfast still06:10
=== chihchun_afk is now known as chihchun
mborzeckimvo: hey, more selinux crap?06:18
mborzeckibtw. https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1826460 is the same story as https://forum.snapcraft.io/t/selinux-warning-when-running-lxc/11100/06:19
mborzeckii seriously don't know what to think of it, oh and 2.39 breaks totally there06:19
mborzeckii reproduced the problem with disco cloud image and installed that weird kernel from the kernel-ppa06:20
mvomborzecki: aha, is that the stacked LSM kernel?06:20
mborzeckimvo: i don't think so, the kernel seems to have AA disabled, and SELinux enabled and default06:26
mborzeckimvo: oh, and once you install the kernel, none of the selinux utils are pulled in06:28
mvomborzecki: woah06:33
mvozyga: there is this work to allow selinux and apparmor in parallel, I was wondering if its that kernel06:38
zygamvo: disco has it06:38
zygaIt landed at the same time as another lxd related bug with shiftfs06:39
mborzeckiah, that's for uid/gid on fs06:43
mborzeckianyways, i don't think it's this kernel06:44
=== pstolowski|afk is now known as pstolowski
mborzeckipstolowski: hey07:03
mborzeckileft a note under https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1826460/comments/307:04
zygahey PaweΕ‚ :)07:04
mborzeckiidk, maybe we could somehow guess the system is using a default policy, meaning, nothing probably works an then stop any attempt to use selinux07:05
zygapstolowski: https://github.com/snapcore/snapd/pull/6781 <- 2nd version of static attr fix07:07
pstolowskizyga: yes, i saw it, thank you, will get to it shortly07:07
zygapstolowski: tha main difference is that the changes are made in reloadConnections, not in setup profiles, because this catches system key regeneration07:07
mborzeckistill don't get why someone who's not a kernel developer or test would install some kernel package from a random PPA07:11
zygamborzecki: I know why07:28
zygamborzecki: sergiusens does it because it makes his surface work07:28
zygamborzecki: AFAIK people do it to get modern vega working on older releases07:28
mborzeckizyga: well, but sergiusens is more than capable of making it work07:28
zygamborzecki: some people do it to follow vanilla kernel development07:28
zygamborzecki: but not all people are sergiusens :)07:29
mborzeckizyga: also, if you provide a kernel package for ubuntu, one would expect that it's soemwhat tailored for the distro :P07:31
zygamborzecki: there's an official vanila kernel ppa07:31
zygamborzecki: not tailored at all07:31
mborzeckizyga: it's like someone provided a kernel package from COPR for fedora, which defaults to AppArmor, that'd be fun07:31
zygabut what do I know :)07:31
* zyga could use a 2nd review for https://github.com/snapcore/snapd/pull/675808:05
zygapromise not to push more today ;)08:06
* zyga does more reviews08:12
pstolowskizyga: reviewed static attrs PR08:30
zygapstolowski: thank you!08:37
Chipacamvo: morning sir. Working with sergiusens for a bit yesterday we were both surprised that #6532, which landed in master on 7/3, wasn't in 2.38 which was cut 21/3. My memory of (and, granted, attention to) the release is very poor, so I was hoping you'd know why this was this way08:40
Chipacahttps://github.com/snapcore/snapd/pull/6743 could use a second review if anybody is hankerin' to do one08:41
mvoChipaca: uh, that sounds fishy!08:42
mvoChipaca: aha, I see now. 2.38 was actually branched earlier, 2019-03-05 and at this point we only cherry-picked things targeted for 2.38 :/08:44
Chipacamvo: i suspected something like that08:45
Chipacamvo: but didn't have dates :-)08:45
Chipacaa shame, but ok08:45
Chipaca(sergio was all ready to use that feature :) )08:45
mvoChipaca: it wil be in 2.39 which is not that far away08:47
* pstolowski running quick errand, afk for a while08:55
zygaChipaca: I wanted to review https://github.com/snapcore/snapd/pull/6743 but I noticed I already did08:58
* Chipaca hugs zyga 08:58
Chipacazyga: thank you08:58
zygaChipaca: wanna do a quick 2nd +1 for https://github.com/snapcore/snapd/pull/6758 ?09:02
zygaa part of an ongoing refactoring09:02
Chipacazyga: where is NewUserProfileUpdateContext used for, that it's public?09:12
zygait's used from main.go09:13
* zyga checks09:13
zygaprobably in subsequent patches09:14
zygaChipaca: in 2 patches from this one: https://github.com/zyga/snapd/commit/1ffaae4478d680566b78ead86f3911c5784893ea09:14
zygaChipaca: so not yet, but soon :)09:14
zygaChipaca: https://github.com/zyga/snapd/commits/feature/user-mount-ns-20.9-split-rebased -09:15
Chipacazyga: that's in the same package, isn't it?09:15
zygabut we may need to put it into a library soon-ish so I'm slowly building towards that09:16
zyga(for a new binary)09:16
zygasnap-update-ns and snap-bootstrap-ns09:16
zygawould share most of the code but would behave differently and bootstrap would do some new things too09:16
zyga(bootstrap would also not need the horrid C bootstrap logic)09:17
zyga(as in bootstrap.c, the name overlap is unfortunate)09:17
Chipacazyga: reviewed, mostly. Almost a +1.09:21
zygaChipaca: replied09:23
zygaif it seems I'm relucant to change it it's partially true and because of the changes stacked on top; I can rework locking if you feel strongly about it but even there I would prefer to append a patch to this series (that was tested and "polished" rather than rebase it, mostly to avoid the extra cost09:25
zygapstolowski: hey09:29
zygaquestion to you sir:09:29
zygais this what you expected? https://www.irccloud.com/pastebin/CoMWt6SB/09:29
zygaI would have to add the pair of unrelated snaps for this test to preserve that connection09:29
Chipacazyga: yes I think the lock/unlock pair would be better, but also yes no problem for it to be done further down the series09:31
pstolowskizyga: yes, that's what i expected. do you need to add those snaps because something is unhappy about them missing?09:31
zygaChipaca: in that model, the unlock state would be simply stored in the context, right?09:31
Chipacazyga: yes09:31
zygapstolowski: not unhappy, as the comment states, they are removed on manager startup09:31
zygapstolowski: note that the order of manager startup vs adding snaps is essential09:31
Chipacazyga: or you could just embed the locker09:32
pstolowskizyga: you could add them to the state after instantiating the manager and before carrying on with the test, no?09:34
zygaBecause manager removes unused connections on startup09:36
zygaI would have to add the unrelated snaps before starting the manager09:36
zygaI can do that, just asking if that is what you expected09:37
pstolowskizyga: yes, but that happens in Manager - initialize, when you instantiate the manager in the test. you can alter the state afterwards?09:37
pstolowskizyga: ah i see09:39
pstolowskizyga: perhaps the second test is better to do this09:39
pstolowskizyga: the one that creates a task for setup-profiles09:39
pstolowskizyga: sorry, you're right about the one i commented on09:40
pstolowskizyga: btw https://github.com/snapcore/snapd/pull/6751 is pending some rework right?09:44
zygapstolowski: looking09:44
zygapstolowski: well, it needs tests09:44
zygapstolowski: but I think the place is right09:44
mborzeckipstolowski: some quick fixes for the policy https://github.com/snapcore/snapd/pull/6783 that were caught in 677809:47
zygamborzecki: man, selinux is comple09:53
mborzeckizyga: or just different conceptually09:56
Chipacazyga: π•Œπ•Ÿπ••π•–π•£π•€π•₯𝕒π•₯π•–π•žπ•–π•Ÿπ•₯ 𝔸𝕝𝕖𝕣π•₯09:57
* mvo hugs zyga for "the computer says NO"09:58
zygalol :)10:03
=== Girtablulu is now known as Girt|Vacation
zygapstolowski: updated https://github.com/snapcore/snapd/pull/678110:12
zygathe new thing is https://github.com/snapcore/snapd/pull/6781/commits/dd739571c24e659d0449c0c0ca6314719f30177710:15
* Chipaca goes out for a bit10:19
zygamvo: I think you should review https://github.com/snapcore/snapd/pull/678110:22
mvozyga: full of meetings today but will do10:35
mvozyga: once I get the chance10:35
pstolowskizyga: ty, will look in a bit10:37
zygaChipaca: something like this? https://github.com/zyga/snapd/commit/328b4b471e22609d60b4b4e430a4aa648963c71410:48
zygamvo: thank you!10:48
zygamvo: about https://github.com/snapcore/snapd/pull/6756 - should I rework it to return an error or leave as-is?10:50
zygaChipaca: https://bet365techblog.com/open-sourcing-jingo-a-faster-json-encoder-for-go <- maybe worth prototyping a switch to see what we'd save?10:57
* zyga quick lunch11:16
=== chihchun is now known as chihchun_afk
zygamy body demands coffee11:38
zygamy mind demands coffee11:39
zygaI shall make coffee11:39
zygathough going outside for a bike ride seems lovely too, it's so warm already11:39
zygapstolowski, mborzecki: I have 28C outside, you?11:39
pstolowskizyga: 27 outside. 28 inside.. /o\11:40
zygadesktop-portal-filechooser fails11:43
zygala la la11:43
mborzeckiout to drop the kids off at school for some extra classes, back in 3011:47
jdstrandmborzecki: hey, can you look at https://github.com/snapcore/snapd/pull/6780#discussion_r27891423311:47
jdstrandmborzecki: in 30 :)11:47
=== chihchun_afk is now known as chihchun
zygajdstrand: I pushed some things to https://github.com/snapcore/snapd/pull/671411:57
zygahey :)11:58
zygajdstrand: (also replied to all the comments there)11:58
zygajdstrand: the /tmp thing has left one question in my mind11:59
zygajdstrand: on regular systems with classic packages /tmp is not private11:59
zygajdstrand: so if an app invoked by another user on this system drops a file that just happens to be readable by my user, well, tough luck, it'd better not contain secrets12:00
jdstrandthat's just normal dac12:00
zygajdstrand: the question is: why is snap /tmp different? could we just make /tmp/snap.$SNAP_NAME/ with 0177712:01
jdstrandthe /tmp should still be 1777 root:root12:01
zygajdstrand: note, in my question I eliminate the presence of intermediate root:root 0700 base directory12:01
jdstrandit doesn't really need to be different. iirc, you are doing 0700 at that point only to bind mount on it and then later chmod 177712:02
zygahmmm, we don't bind mount on it AFAIK12:02
zygaor perhaps we do but that's something that we could change12:02
jdstrandyou are otherwise it wouldn't be known as /tmp in the mount namesapce... ?12:03
zygathat is, we could mkdir 01777 and then bind mount that over /tmp (so not over /tmp/$RANDOM/tmp but over constructed-snap-rootfs/tmp12:03
zygayeah, but we construct the root filesystem in a different way now (on the side) and the very old code that manages /tmp could be adapted to that style too12:03
zygawe could even mount a tmpfs there and call it a day (no visibility from initial mount namespace) but I think that was ruled out because of space constraints12:04
jdstrandI'm not opposed to that changing. the main thing is, the result needs to be root:root 1777 and the getting there needs to be race-free12:04
zygajdstrand: can you expand on the race-free aspect?12:04
jdstrandzyga: I don't think we want to mount a tmpfs there12:04
zygajdstrand: (agreed on tmpfs)12:05
jdstrandzyga: we are actively not doing that because a tmpfs can take up to 50% of ram and those cause low memory12:05
jdstrandzyga: race free> yeah, however we get there, there can't be a possibility of an unprivileged user (or a snap at all) to to symlink attacks, etc12:06
zygawe protect against some of the attacks on mount with our special mount code in snap-update-ns but we don't have a C equivalent AFAIK12:07
zygajdstrand: as far as I'm aware only mount is really susceptible to a race attack, out of the primitives we use12:08
zygajdstrand: I'm trying to find a solution that would be devoid of edge cases, correct, not insecure (see what I did there :), and usable for people12:08
jdstrandzyga: I think you are not taking my point as intended12:08
jdstrandzyga: we have a property now where we are race free. with the rename to a fixed dir or the rewrite you are sugggesting, we want the same property12:09
zygajdstrand: no disagreement there12:10
* jdstrand takes deep breath12:13
jdstrandwhy is sid failing to build all of a sudden: https://paste.ubuntu.com/p/k9nYZkrSgP/12:14
zygajdstrand: where are you seeing this?12:15
zygain the sbuild test?12:15
jdstrandI can't get out from under constant problems with this PR... /o\12:15
jdstrandzyga: I saw it didn't build here: https://travis-ci.org/snapcore/snapd/jobs/52470774412:16
zygajdstrand: hey do you remember user mounts? :D12:16
* zyga looks12:16
jdstrandzyga: it did not have great logs, so I tried in a local qemu12:16
zygajdstrand: it's going to be all right, it's just one of those moments where you improve things for many people, not just snap users, by fixing bugs blocking your work12:16
jdstranduse -debug with spread and then rewound and did:12:16
jdstrandcd /home/gopath/src/github.com/snapcore/snapd12:17
jdstrandcd _build && go install -gcflags=all=\"-trimpath=/home/gopath/src/github.com/snapcore/snapd/_build/src\" -asmflags=all=\"...12:17
jdstrandas shown by the -debug output12:17
jdstrandzyga: yes, that's true. it is just been nuts12:17
jdstrandin this case, I don't know what bolt is. I do know what libseccomp-golang is, and I'm puzzled why sid is not working with the distro golang-seccomp12:19
* jdstrand shakes fist12:19
jdstrandit seems to not be installed. why?12:19
zygahow we ignore errors in some places? https://www.irccloud.com/pastebin/4jf6qJKw/12:19
* jdstrand looks12:19
zygajdstrand: I'm trying to make sense of that but I see more magic12:20
* jdstrand is puzzled. these packages are in the build-depends12:20
zygasrc/github.com/snapcore/snapd/cmd/snap-seccomp/main.go:655:10: undefined: seccomp.ActLog <- this seems to say that golang-seccomp is older?12:21
zygajdstrand: build-depends vs vendorized12:21
jdstrandI'm wrong, it is installed12:22
jdstrandzyga: ah. ok. yes12:22
zygapackage from debian took priority?12:23
jdstrandzyga: man I skipped right over that12:23
jdstrandok, I see what to do12:23
jdstrandmborzecki: do you think if I just added the 4th field to system-key it wouldn't be a big deal?12:24
zygajdstrand: but does that mean we won't be able to build de-vendorized in sid?12:24
zygajdstrand: the sbuild test should show that btw, if that breaks next we need to update golang-seccomp in debian12:24
jdstrandzyga: I can make it work. it worked before12:24
zygajdstrand: system key is flexible, just check how costly it is to compute because snap run does it12:24
jdstrandI made a small changge to tyhicks initial patch which apparently broke it12:24
jdstrandzyga: adding the 4th field couldn't be cheaper. it is that string match12:25
mvozyga: sorry for the delay - 6756 is afaict no longer needed, the change that landed recently checks for nil and returns an error now12:25
zygamvo: oh, where was that?12:26
zygamvo: please comment in the PR and feel free to close it12:26
mvozyga: thanks, will do12:26
jdstrandmborzecki: nm, I'm going for it12:26
mborzeckijdstrand: i wouldn't mind, it's an implementation aspect, not user facing, but nothing i would block on12:27
zygajdstrand: I will be much happer once, one day, I will replace all of snap-seccomp with pure go code12:27
mborzeckijdstrand: though once it's collected & parsed in backend init, you could do whatever later on in the code, no need to call snap-seccomp once again12:27
mborzecki(unless for compilation obviously)(12:27
zygajdstrand: and can remove that from system key for that extra oomph speed for snap startup :)12:27
zygamborzecki: note that snap-run does this every time AFIAK12:28
mborzeckizyga: yes, it also picks up build ids and so on12:28
jdstrandzyga: well, I think you cannot do that without removing libseccomp cause libseccomp is C code and CGO_ENABLED=0, but I don't want to go there12:29
zygamborzecki: does it mean snap-run will run snap-seccomp with some query argument each time on every run?12:29
zygajdstrand: yes, that's what I meant12:29
zygabut don't worry, I'm sure we will slowly get there, with enough checks to be confident we are producing the same bpf as before12:29
mborzeckizyga: it's part of system-key, so yes12:30
zygamborzecki: would be good to time that12:30
zyga(on a pi for example)12:31
jdstrandzyga: I can't say how worried I am about that any more than I have. we should *not* reimplement libseccomp. the world has standardized on it and it is tricky code. we will trade one set of problems that everyone faces and has a desire to fix for another that only you could fix and no one else cares12:32
mborzeckizyga: afaik we call apparmor_parser too, woulnd't expect snap-seccomp to be slower than that12:32
jdstrandbut I don't have time to debate this12:33
Chipacaoops, wrong place12:34
mborzeckioffshows :)12:34
Chipacathat was a comment about you and zyga having ~28C12:34
Chipacadidn't notice i was scrolled way up12:35
Chipacazyga: looking at your locking code now12:35
zygaChipaca: I pushed a 2nd branch that fixes a typo in the branch name but it's otherwise identical12:35
Chipacazyga: calling Unlock when it's not locked would usually be a panic()12:36
zygaChipaca: +1, easy change12:36
Chipacazyga: either implicit or explicit I don't mind :-)12:36
mborzeckihmm a bunch of snaps mounted locally, somehow udisks insists on showing 2 of them as normal disks, wtf?12:37
zygamborzecki: that's a local patch to udisks or you lost your mtab state12:37
Chipacamborzecki: that seems to happen when something is using and old core12:38
jdstrandmborzecki: jdstrand: though once it's collected & parsed in backend init, you could do whatever later on in the code, no need to call snap-seccomp once again12:38
mborzeckiChipaca: yes, that would be it12:38
jdstrandmborzecki: I recall looking at that and had some trouble. what are you suggesting?12:39
jdstrandmborzecki: reading it off the disk?12:39
Chipacamy typo-ing rate today is quite high12:39
Chipacaseem to be typing phonetically a lot12:39
mborzeckijdstrand: iirc version info is kept in seccomp backend struct12:39
jdstrandmborzecki: (this was the bit where I said 'there were multiple ways of doing this' in my PR12:39
jdstrandmborzecki: that isn't available way out in overlord/snapstate12:40
jdstrandmborzecki: I was hoping to extract it from somewhere via interfaces/system_key.go but resorted to a callout to snap-seccomp12:41
Chipacaaugh. There's a Jesse Lenton somewhere in Winnipeg that's receiving some documents via a secure online thing, but they've given my email for it … so if anybody wants to find out some dirt about some employees of some random corp in canada, hit me up12:42
jdstrandmborzecki: afaict, snapd doesn't maintain system-key in memory. it has it on disk and at strategic times, recalculates and compares to waht is on disk12:43
mborzeckijdstrand: hm that's probably easier, the cache info is well hidden under interfaces :/12:43
jdstrandmborzecki: but I could read it from disk12:43
jdstrandmborzecki: I was somewhat hesitant of that though12:44
jdstrandI mean, it *should* be ok12:44
mborzeckijdstrand: imo calling the compiler again sounds reasonable12:44
jdstrandmborzecki: ok, that is where I landed. I'll add the fourth field then I just have the one callout12:45
mborzeckijdstrand: unless, there would be like an instance of seccomp.Compiler() set up to use snap-seccomp kept somewhere12:45
mborzeckijdstrand: hm otoh, that microoptimization is probably not worth it, so a second call to snap-seccomp sounds ok to me12:46
jdstrandmborzecki: again, where I landed with 'picked something that made sense to me' :)12:47
jdstrandmborzecki: thank you for discussing this here12:47
* Chipaca wanders off to make tea12:55
=== chihchun is now known as chihchun_afk
zygaChipaca: thanks for sharing that error talk!13:33
zygaI'm very interested in error handling in both Go and C13:33
Chipacazyga: there's also a very good one about constants I think you'd enjoy13:33
Chipacazyga: https://www.youtube.com/watch?v=pN_lm6QqHcw13:34
zygaChipaca: opened in another tab13:34
zygahttps://github.com/snapcore/snapd/pull/6785 is green13:35
* zyga uses social engineering tricks to get reviews13:35
* Chipaca hires a russian bot farm to -1 zyga's PRs and thwart his social engineering campaign13:36
* Chipaca buys some sweets with the change13:36
zygaChipaca: we could move code review to twitter and facebook :D13:36
zygaChipaca: so can we start to stop using fmt.Erorrf :)13:37
Chipacazyga: well we shouldn't :-)13:37
Chipacabecause they hacked fmt.Errorf :-D13:37
Chipaca(continue the talk)13:37
zygadrat, that's like we watch a movie together but you know the ending :D13:37
* zyga watches13:37
Chipacaas long as it's fmt.Errorf("yadda yadda %v", err), or %s err, it'll DTRT13:37
zygait groks the argument is the wrapped error?13:38
Chipacazyga: also the error crawls up its butt and explodes it from the inside13:38
zygaand stores it as well?13:38
Chipacasomething like that? i haven't tried it :-)13:38
zygajuju/errors :)13:39
zygaChipaca: so will golang 2.0 switch to spaces and ban tabs?13:39
zygaor will it be something we can reasonably be on in the next 12 months after it ships?13:39
Chipacaall those big 2.0 features are getting worked into 1.x13:40
Chipacathat was one of the things that came out of the 2.0 discussions13:40
zygaso what will 2.0 bring?13:40
zygathat's not in 1.x?13:40
Chipacazyga: actual incompatible things left over?13:41
zygausing interfaces is so natural in go13:41
Chipacazyga: basically they don't want to be python13:41
zygathat's a neat idea13:41
zygaChipaca: a bit of what I'm hearing starts to feel like objc13:42
Chipacazyga: i haven't used objc in anger, so i don't have a strong opinion of it either way13:43
Chipacazyga: but i also don't know what you mean :-)13:43
zygaChipaca: the highly dynamic aspect13:43
Chipacai think the only time i've used objc it was actually c with some weird bits (rather like how i've used c++)13:44
zygathe errors.As thing is odd, why on earth is it returning a boolean?13:45
mborzeckizyga: sounds like you really want that pkg/errors package :)13:47
zygamborzecki: not sure yet13:47
zygaI see their point about how those are weak13:47
Chipacazyga: errors.Is returns a boolean13:49
zygaChipaca: yes, but As ?13:50
zygaChipaca: I was expecting some form of casting but perhaps I misunderstood that13:50
Chipacazyga: so you tell it the type by passing it a thing, so it sets that thing to the matching one and tells you that it succeeded via the bool13:51
zygaah, so it writes to the target13:51
zygaI thought it just uses that for type information13:52
zygathat makes sense now13:52
zygathough ugly because golang and generics but that's all right13:52
Chipacazyga: (?i) makes the (containing sub)regexp case-insensitive from there to end or (?-i)13:56
zygaI read the replies from Maciej13:57
zygamborzecki: +113:57
Chipacazyga: you can also do (?i:regexp) and have that subregexp be case-insensitive13:57
* zyga liked the RE_I flag or whatever that was called in other systems 13:57
Chipacazyga: other systems also support these flags13:58
Chipacai mean, this is taken from perl regexp syntax13:58
Chipacaperl, python, and pcre all also support making it case insensitive outside of the regexp though13:58
Chipacaand yes that is clearer, to me13:58
Chipacabut Β―\_(ツ)_/Β― go's purportedly-perl-compatible regexps (which aren't) have that nice predictable non-pathological time characteristics, so that's nice instead13:59
Chipacabtw perl's regexp support for unicode is _still_ unmatched13:59
* Chipaca looks into outsourcing reviews14:02
zygaChipaca: those russian trolls, do they do reviews too? :)14:09
Chipacazyga: i'm sure they do14:10
cachiomvo, could you please include this pr #6694 to next 2.3914:10
cachiomvo, you merge all the PRs with milestone 2.39 right?14:11
cachiomvo, otherwise I can provide you a list of PRs which I need on 2.3914:13
zygaChipaca: watched both now14:15
cachiojamesh, hi14:22
cachiojamesh, I am testing snapd on 19.04 and 1 test is failing https://paste.ubuntu.com/p/YN44WYGCM5/14:24
cachiodoing xdg-open snap://package14:25
cachiojamesh, I was researching and found that it fails when the package gnome-settings-daemon is preinstalled14:25
zygamvo: can we merge https://github.com/snapcore/snapd/pull/671714:26
cachiojamesh, were you aware of this problem?14:27
mvozyga: looking14:38
mvozyga: scopedTracker is a strange name14:38
zygamvo: perdronis changed it14:38
Chipacamvo: do you know why we allow installing ubuntu-core still?14:38
mvozyga: yeah14:38
zygamvo: so I guess it is his informal +114:38
mvoChipaca: wuuut? we do?14:38
zygamvo: wrt to name14:38
mvozyga: yeah14:39
zyga(insert chipaca emoji)14:39
mvozyga: hahaha14:39
zygaI don't care, it's important to fix the bug more than to have a fun name14:39
mvozyga: I'm with you on that14:39
Chipacamvo: yes we do. Needs to be part of a multi-snap install; we block it for single snaps14:39
zygamvo: shall I merge it then?14:40
mvozyga: yes, looks sane14:41
Chipacazyga: there is as yet no chipaca emoji. But we've got a mate emoji, so the chipaca can't be far behind!14:41
mvoChipaca: aha, I see14:41
Chipacamvo: i'll fix14:41
zygamvo: merging, thanks!14:41
=== chihchun_afk is now known as chihchun
mvoChipaca: thank you14:44
Chipacamvo: https://github.com/snapcore/snapd/pull/6786 fwiw14:57
mvothanks Chipaca15:06
zygaChipaca: s/also//15:06
zygaChipaca: +1 though a spread test would be nice15:07
Chipacazyga: why no also?15:07
zygait reads oddly, not sure ;)15:07
Chipacaah ok15:07
zygasaying "daemon: verify snap instructions for multi-snap requests" reads better15:07
Chipacai also removed the extra space your regexp left behind15:08
zygadarn, I was thinking about that15:09
zygalast thing of the day: spread test for the mount bug15:09
Odd_Blokejdstrand: I'd love your thoughts on https://forum.snapcraft.io/t/potential-additions-to-account-control-interface/11123/115:35
ChipacaOdd_Bloke: is the snap you're building only for use on ubuntu core?15:37
Odd_BlokeChipaca: At the moment, I'm just doing exploratory work to see what would be required to strictly confine cloud-init; this was one of the things that I found I had to add a `system-files` interface for, despite us having an interface that sounds like it would include them.15:39
=== chihchun is now known as chihchun_afk
ChipacaOdd_Bloke: account-control is all about core tho15:40
Odd_BlokeThere is nothing in the docs that indicates that to be the case, AFAICT?15:40
Chipacathe docs might need updating; it's an old interface15:41
Chipaca# Only allow modifying the non-system extrausers database15:41
Chipaca^ that's from the code15:41
Odd_BlokeThe docs say "account-control allows managing non-system user accounts."15:41
Chipacayes i can read15:41
ChipacaOdd_Bloke: sorry, not sure where that came from15:41
ChipacaOdd_Bloke: yes the docs might need updating, if I've got this right15:42
Chipacai'm not an expert on this bit of the code, jdstrand was the right person to ask15:42
Chipacabut, from what's in the code, this will only work in core15:42
jdstrandI responded15:45
* cachio lunch15:47
jdstrandok, rewrote the actlog PR: https://github.com/snapcore/snapd/pull/678715:49
jdstrandit was a more involved pr, but cleaner in the end, so I thing that is a good thing15:49
Chipacazyga: hostname-control might need a similar warning?15:55
Chipacazyga: OTOH if they're only for core, why have them in classic at all?15:55
zygaChipaca: TIF15:55
* Chipaca goes15:55
Odd_BlokeI think hostname-control is useful on classic?15:56
Odd_BlokeIt gives write access to /etc/hostname and exec on hostnamectl.15:56
jdstrandOdd_Bloke: sure. it has no restrictions like that (just rememeber to snap connect it)15:58
jdstrand(it is manually connected by default, which can be adjusted with a snap declaration)15:58
Odd_BlokeI also had to add a few system-files rules to allow me to manage networking from cloud-init (on classic); is network-control expected to be a core-only thing, or is that worth opening up a topic for?15:59
jdstrandOdd_Bloke: it is for anyone. please open a topic16:03
Odd_BlokeWill do.16:03
jdstrandOdd_Bloke: I'll be doing some profile bug fixes for 2.39 and will add that to the list16:03
Odd_BlokeOh, actually, I hadn't seen network-setup-control until I typed in my topic title, let me see if that makes a difference.16:06
Odd_BlokeOK, that's simple enough to just read.16:07
zygajdstrand: does https://forum.snapcraft.io/t/snapping-a-font/11122/2?u=zyga sound sensibly?16:23
jdstrandzyga: it would help. with fonts it probably isn't bad. with arbitrary content like images, sounds, movies it would be rather heavyweight16:27
Odd_Blokejdstrand: https://forum.snapcraft.io/t/network-control-network-setup-control-doesnt-enable-running-netplan-generate-on-classic/1112616:33
zygajdstrand: fonts contain full VMs nowadays, you know?16:36
Odd_BlokeISTR there were font cache versioning problems recently, too?16:37
Odd_BlokeThat might make fonts a little trickier?16:37
Odd_Bloke(I recall none of the details.)16:37
zygaOdd_Bloke: yes, at runtime, but not for distributing the font by itself I think16:37
zygabut yeah16:37
zygait compounds the problem16:37
Chipacazyga: wrt fonts etc, couldn't we sanity-check them server-side?16:38
zygaChipaca: that's an interesting idea, perhaps we could16:38
zygaChipaca: but it would be tricky for one reason16:39
zygaChipaca: when you find that you were not checking for something that is evil and you said it was fine before you have to revoke that decision16:39
zygaChipaca: in a filter approach you can provide a refresh to the filter package and re-generate content16:39
Chipacazyga: yeah16:39
zygaChipaca: thereby neutering the invalid blob16:39
zygaChipaca: I think it's all a scale of paranoia16:40
zygaone could say that some type of content is plausibly ok to ship without a filter16:40
ChipacaCM fonts16:40
zygaChipaca: some things can be chameleons and can be interpreted as many things at once16:40
zygait's complex but for some stuff I'd love to have it16:40
zygawallpapers and fonts are a good candidate16:40
Chipacafonts should be shipped only as metafont instructions, launchpad builds it into a snap that's gtg16:40
zygajdstrand: https://github.com/snapcore/snapd/pull/6787#pullrequestreview-23125447416:47
Chipacai now have two (2! which is also 2) PRs that are green and just need another +1 to land16:48
* Chipaca also has more prs than just those, but these two are Special16:49
* Chipaca puts the PRs in the short bus16:49
zygaChipaca: wanna read https://github.com/snapcore/snapd/pull/6785 ?16:54
zygaI could bug mvo for +2 and then open the next chunk :)16:54
zyga(only about 5 left)16:55
zygathis is a +12 βˆ’13 PR so pretty painless16:55
ijohnsonjdstrand: any chance you'll get a chance to review 6697 (about daemon-notify) soonish? if not that's fine I can workaround it but it would be better to know ahead of time if that workaround is likely to be necessary16:55
Chipacazyga: why is 1000 the right thing instead of os.Getuid()16:59
Chipacazyga: ?16:59
jdstrandijohnson: the workaround is likely necessary. possibly next week17:01
zygaChipaca: because the test uses 1000 a line above :)17:14
zygait's a fixed value17:14
zygaChipaca: read the 2nd commit plase17:14
zygaChipaca: sorry for the lag, I went upstairs to stretch and found pizza lefttovers :D17:14
zygamvo: pretty please a 2nd review on https://github.com/snapcore/snapd/pull/678517:16
zygaChipaca: thank you!17:16
zygaChipaca: for on this line https://github.com/snapcore/snapd/pull/6785/commits/0917f2460ae1d8dbe19823c32d79773add5addb1#diff-fca81d6060b39fa4cf7450a9d05bd004R38417:17
* zyga EODs17:28
ijohnsonjdstrand: ack thanks18:21

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!