[00:35] Bug #1677417 opened: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system

=== chihchun_afk is now known as chihchun === hikiko_ is now known as hikiko [07:17] who can help me with tracks in the store? [07:22] mwhudson: maybe open a store side question on the forum? [07:23] zyga: did the forum get mentioned on the mailing list yet? [07:23] mwhudson: it's metioned in the topic here :) [07:23] yes, that's the only place i've seen it mentioned [07:23] mwhudson: I think it will replace the mailing list entirely [07:23] * mwhudson gives an old man sign [07:23] *sigh [07:29] https://forum.snapcraft.io/t/can-someone-set-up-guardrails-for-the-go-snaps-tracks/72 [07:29] also autopublishing to tracks from launchpad would save me a lot of effort :) [07:31] mwhudson: ping [07:32] morphis: hi [07:32] mwhudson: hey! how are things? :-) [07:32] morphis: not bad! [07:33] mwhudson: sounds good, I saw you're one of the maintainers of snapd in debian [07:33] morphis: yeah [07:33] mwhudson: any concrete plans to update the package real soon? [07:33] morphis: no, debian is in freeze [07:33] don't we have a package in unstable too? [07:33] morphis: i thought re-execing in the core snap mostly meant i didn't have to [07:34] well yeah but life is easier if stable and unstable don't diverge aiui [07:34] mwhudson: I think we could file an RC bug because we need to ship something or the package is totally broken :/ [07:34] i could upload a newer one to experimental [07:34] zyga: right, if we need to fix this core snap hanging thing with a new package, we need to do that [07:34] mwhudson: we had a few serious issues recently which are now patched in snapd 2.23.6, though I didn't checked yet if debian is affected [07:35] * zyga reboots to try new pulseaudio [07:36] mwhudson: let me try the current snapd package in testing [07:37] morphis: i've not dealt with the politics of getting a release exception in debian [07:37] mwhudson: ok, so lets see if we an avoid this :-) [07:37] morphis: but it's at least possible that targeted fixes will be an easier sell than a wholesale upgrade [07:37] or not, i don't know [07:38] mwhudson: I think if there are single fixes needed to get snapd in debian re-exec into the one coming from the core snap we can do that [07:43] zyga: https://bugzilla.opensuse.org/show_bug.cgi?id=1031501#c3 [07:48] morphis: looking [07:48] morphis: so 1) this will only work if home interface is connected (it doesn't even have to be used) [07:48] morphis: why does every non-snap app work? [07:49] morphis: there must be a different auth mechanism that is being tried [07:49] morphis: it fails and xauthority is a workaround [07:49] maybe [07:49] that is what I am currently looking into [07:49] zyga: it wouldn't even work with the home interface connected as it doesn't allow you to use .XAuthority [07:50] it only works in this case because we have no confinement at all [07:56] morphis: ah, right [08:07] zyga: ok, it gets interesting, XAUTHORITY is set to /tmp/xauth-1000-_0 in KDE on suse [08:07] zyga: are we doing any processing of the env vars when we spawn up the snap environment? [08:08] no, as it seems, it ends up the snap in the snap env [08:09] morphis: aha [08:09] morphis: see [08:09] morphis: it is /tmp related :) [08:09] zyga: flatpak is doing some extra stuff here [08:09] see https://sources.debian.net/src/flatpak/0.8.4-3/common/flatpak-run.c/?hl=1944#L1924 [08:09] morphis: yes, I think we need to extra stuff for x11 and pulseaudio [08:10] morphis: that feels like snap-confine's work [08:10] morphis: you could read the xauth config on startup [08:10] morphis: and after dropping privs write the file into the fresh /tmp [08:11] morphis: (remember that tmp is empty) [08:11] zyga: right [08:11] similar to what flatpak does [08:14] morphis: yeah [08:14] morphis: right now I'd code it in C directly [08:14] morphis: but I sooomewhat worry about how many hacks like this we'll need [08:14] morphis: I suspect that a bound set so this is oK [08:14] morphis: if it starts to look like each new interface needs this we may have to think about snapd assisting via a backend [08:14] zyga: right [08:15] zyga: lets start with a hack into snap-confine [08:15] actually this is kind of a problem and wondering if the KDE guys didn't experienced this problem with their snaps [08:16] zyga: let me take this problem as part of my cross-distro work [08:26] Son_Goku: ping [08:26] pong [08:26] :/ [08:30] Son_Goku: you saw the PR for the missing not upstream patch? [08:30] yes [08:30] I already added the comment to my spec [08:30] good [08:30] I'm rebasing to 2.23.6, since you guys released that yesterday :/ [08:30] Son_Goku: :-) [08:31] and I've already been bitten patchwise [08:31] in which way? [08:31] the systemd unit template PR doesn't apply cleanly onto 2.23.6 [08:31] the rules file hunks all fail [08:31] so I've been purging those manually from the patch [08:32] yeah those things are nasty [08:32] Son_Goku: so really time to get them all dropped :-) [08:32] Son_Goku: I am trying to get that solved with 2.24 [08:35] is seccomp still broken for 2.23.6? [08:36] morphis ^ [08:38] Son_Goku: we have fixed one bug but I fear there might be more [08:38] so still broken, yay :( [08:38] not directly broken [08:39] but as AppARmor is disabled we may run into situatuions where things would have been blocked already by AppArmor and not run into seccomp denials which lead to hanging processes like we had for snapctl [08:39] Son_Goku: once we're done with the basic packaging bits I will start working on getting proper CI up for fedora/debian/suse/.. [08:40] then we have a much safer way of handling and testing those things and can ensure they keep working [08:40] I feel like banging my head into the ground with all this shit... :/ [08:40] alright, I'm turning back on seccomp and damn the consequences [08:41] Son_Goku: things will be much easier once we have all patches upstream [08:42] and confinement is on my list too [08:42] I hate golang so much [08:42] it just adds so much complication to things [08:42] :-) [08:43] I used to merely dislike golang, now I hate it [08:45] hey morphis, sorry I was not around when you pinged yesterday and it was a contentless ping so couldn't reply when I came back ... I guess it was about that KDE/opensuse issue you are discussing on the list and now here? [08:46] seb128: right, I thought you might be one who knows what is going on but I've figured the real problem already: https://bugs.launchpad.net/snapd/+bug/1677513 [08:46] Bug #1677513: snap-confine does not pass file referenced by XAUTHORITY env variable into the snap environment [08:47] seb128: didn't checked KDE on Ubuntu yet but they might set XAUTHORITY to something in /run or /home too [08:47] seb128: but thanks for the late pong :-) [08:47] np, glad that you figured it out :-) [08:52] well, here we go... [08:53] morphis: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678557 [08:53] Son_Goku: awesome! [08:54] mvo: #3109 is mergeable, no? [08:54] Son_Goku: will give this some testing once ready [08:55] oh crap [08:55] I just realized something [08:55] ? [08:57] I need to pull in my snapctl patch [08:57] for selinux [08:57] that was almost certainly not merged back in to 2.23.6 [08:58] not knocking on mvo, but this was not exactly something he cared about for merging back into releases before [08:58] Son_Goku: ah, is that one already in master? [08:58] yes [08:58] ok, another one we can drop with 2.24 then.. [08:58] since the debubuntu packages don't ship the selinux module as a subpackage yet, he has no way of knowing or caring about changes to it [08:59] right [08:59] Son_Goku: this will get better once we have CI also caring about fedora [08:59] I doubt it [09:00] it'll be hard to spot selinux backport things because the domain is in permissive mode [09:01] I see [09:01] something I need to dive into at a later point [09:02] generally, selinux policy module changes should be assumed to be backported, I think [09:03] as they are generally reactive from when you guys change something, rather than proactive [09:07] Son_Goku: hey, sorry that some bits did not get backported, we want to do a 2.24 soon though. we did the 2.23.6 mostly to ensure we have some important bugfixes out before moving on. once 2.24 lands things should move more normal again, i.e. things in master also go into the release etc [09:08] mvo: no worries [09:08] I blame morphis anyway :P [09:08] (not really!) [09:08] Son_Goku: :-D [09:09] anyway, I expect that this will get better, vis-a-vis the selinux module, once someone adds the packaging for it to debubu packaging [09:10] what I'm going to hate doing is packaging DNF debian-style for snapcraft [09:10] I despise Debian-style packaging (I consider it way more complicated than it should be) [09:10] it's not that I don't know how to do it... I certainly do [09:11] after all, I used to use Ubuntu for years and almost became a Debian/Ubuntu contributor many years ago [09:13] fuck [09:14] snapd FTBFS on i686 [09:14] and ppc64 [09:15] well, at least it built on ppc64le [09:15] https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723 [09:17] Son_Goku: ah, I have a fix for that one [09:18] * Son_Goku groans [09:18] Son_Goku: https://github.com/snapcore/snapd/pull/3094 [09:18] PR snapd#3094: cmd: rework header check for xfs/xqm.h [09:18] yay [09:18] more patches [09:18] Son_Goku: with that everything should build fine, verified with https://copr.fedorainfracloud.org/coprs/mrmorph/snapcore/ [09:18] you don't have a fix for ppc64, though [09:19] which doesn't build for ppc but for i386 [09:19] yeah looking into that one .. [09:20] Son_Goku: can I easily cross build with mock? [09:20] no [09:20] mock does not support foreign arches like that yet [09:20] BUT [09:20] Fedora offers contributors access to ppc64 VMs [09:20] ah [09:21] morphis: I suggest hopping into #fedora-ppc and asking about it [09:23] Son_Goku: will do, need to care about a few other things first [09:27] pedronis: what retry interval do we have in snapd currently to reach the serial-vault as configured from the prepare-device hook? [09:30] morphis: 1 minutes for dynamic errors, for things that look like the vault is not understanding a back off starting from 5 minutes and then doubling up to a max [09:31] morphis: and joy of joys [09:31] armv7hl failed too [09:31] pedronis: ok, but we don't block the further first-boot process when we can't the server, right? [09:31] Son_Goku: wonderful .. [09:31] full list of failures: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723 [09:31] morphis: first boot is completely independent, they are even two different changes [09:31] morphis: what we block is the fist refresh for a bit [09:32] we try to refresh witha serial if possible [09:32] but after a while try anyway [09:32] morphis: it looks like arm failed because of same issue with i686 [09:32] pedronis: ok, just wanted a confirmation on this [09:32] Son_Goku: yeah, which is a "good" thing :-) [09:38] morphis: added patch, and trying again: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977 [09:38] Son_Goku: great [09:46] mvo: can you please have a 2nd look at https://github.com/snapcore/snapd/pull/3102 [09:46] PR snapd#3102: interfaces/mount: add function for parsing mount entries [09:46] morphis: now i686 just fails to compile :( [09:47] /usr/include/xfs/xfs.h:51:12: error: size of array 'xfs_assert_largefile' is too large [09:47] extern int xfs_assert_largefile[sizeof(off_t)-8]; [09:47] morphis: you need to go back to the drawing board on this [09:48] I see you two are having fun :) [09:48] * Son_Goku groans [09:48] I wanted this to be released already [09:48] I want the buildsys to stop telling me that snapd-glib is broken [09:48] I start to see light at the end of my tunnel [09:49] with the move to go the coding moves faster than before [09:49] Son_Goku: hm, this worked for me well in Yocto .. [09:49] I see crushing sadness and dispair [09:49] morphis: Yocto is bullshit [09:49] Son_Goku: lets not get into this discussion, please :-) [09:49] Yocto can be whatever you want, so it doesn't really serve as a great means of comparison [09:50] Son_Goku: you have a link to the last build? [09:50] Son_Goku: I think the more interesting fact is that it built on 32bit debian [09:50] zyga: Debian has older compiler [09:50] Son_Goku: sid? [09:51] Son_Goku: very doubtful [09:51] has debian moved onto GCC 7 yet? [09:51] as far as I knew, they were still on 6.3.x [09:51] Son_Goku: yes [09:52] are you using hardened build flags there? [09:52] https://packages.debian.org/experimental/gcc-7 [09:52] because Fedora does by default [09:52] Son_Goku: I don't know [09:52] I know Debian does not [09:52] but dones't look like related to what the error above says [09:52] it does look like the size of off_t is the relevant factor here [09:52] but TBH [09:52] this is all load of BS [09:52] zyga: anyway, gcc-defaults in sid is gcc6 [09:52] because we should just check if that header file exists [09:52] https://packages.debian.org/sid/gcc [09:53] all we need are _constants_ [09:53] morphis: feel free to hardcode those as those are kernel constants and kernel is not insane to change [09:53] morphis: and drop libxfsprogs-devel from dependencies [09:53] morphis, zyga: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977 [09:53] the green, orange, and red links are clickable :) [09:54] the ppc one is interesting, checking [09:54] zyga: you propose that as an upstream change? :-) [09:54] here's a previous failed build, too, prior to adding snap-confine patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723 [09:54] morphis: as a distro change and upstream change later [09:54] morphis: I see no reason to check linkability or work around this issue [09:54] morphis: if we care about a hanful of constants [09:55] Son_Goku: ok, this looks different now [09:55] the failures are possibly caused by newer libxfs [09:55] maybe [09:56] Fedora has xfsprogs 4.10.0 [09:56] Debian has xfsprogs 4.9.0 [09:56] since we update the kernel, we also update the tools too [10:01] Son_Goku: my guess is that we should get this building with add -D_FILE_OFFSET_BITS=64 to CFLAGS [10:01] patch? [10:03] Son_Goku: something like https://paste.ubuntu.com/24280132/ but didn't tested it yet [10:04] easy to test, I can just fire off a scratch build for it [10:04] okay, I'm getting super sick of this [10:04] someone needs to turn off OpenID auth on raw pastes [10:04] morphis: if no one fixes that, please stop using paste.ubuntu.com [10:05] :-) [10:06] Son_Goku: I bet there's a reason for that [10:06] zyga: I don't care [10:06] it's stupid and aggravating and I can't curl anything [10:06] morphis: please use paste.fedoraproject.org, if you need an alternative [10:07] there's also a handy fpaste utility for pasting from the CLI :) [10:07] https://pagure.io/fpaste [10:07] * zyga wonders why not pastebinit + config [10:08] well, I didn't know about pastebinit :) [10:08] it supports many paste services [10:09] simple python script AFAIR [10:09] it has a fpaste config [10:10] though I don't know if it works with the new pastebin software fedora deployed recently: https://fedoramagazine.org/hello-modern-paste/ [10:11] Son_Goku: looks nice [10:12] Son_Goku: I honestly don't like the new paste, there was a looot of negative feedback after it was rolled out [10:12] Son_Goku: I need to try it again though, I think/hope some of that feedback was addressed [10:12] I don't care for it's look and the superlong URLs [10:13] Son_Goku: the URLs were totally broken wrt basic usaility [10:13] *usability === carlolo_ is now known as carlolo [10:16] morphis: trying a scratch build with your diff: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679354 [10:16] ok [10:17] ah [10:17] it wont work [10:17] needs to be = instead of += [10:17] Son_Goku: sorry for that [10:18] Son_Goku: https://paste.fedoraproject.org/paste/-NaL-TKvNct9~lx1tvVDdl5M1UNdIGYhyRLivL9gydE= [10:18] does that mean all the hardening flags are clobbered? [10:20] no [10:20] if we add AM_CFLAGS then they are there [10:21] Son_Goku: so something like https://paste.fedoraproject.org/paste/k6OU-DUhS5tSIQ5cglQP7F5M1UNdIGYhyRLivL9gydE= is more correct [10:21] Son_Goku: this fork functionality is quite nice [10:21] yes, it is [10:22] ogra: how do you reply with a quote on discourse? [10:22] zyga, just mark something in the text then a "quote" thing pops up [10:22] you also earn a new badge with it ;) [10:22] aah, nice! [10:22] thanks! [10:25] morphis: take 2: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679427 [10:25] Son_Goku: lets hope this now works .. [10:25] since arm takes too long, I'm going to assume it works if i686 does [10:26] then you can prepare a formal PR and I can have a formal patch and we can try again for all arches [10:26] ogra: heh, my quote didn't really work :) [10:27] I wish our discourse supported social sign on [10:27] fixed now [10:27] ogra: have a look at https://github.com/snapcore/core-build [10:27] (not Ubuntu SSO, but normal SSO, like Google, Twitter, GitLab, GitHub, etc.) [10:27] ogra: what else do we need there? [10:28] Son_Goku: I think it doesn't upstream and that's why we don't have it here [10:28] weird [10:28] Son_Goku: and as a plugin it is not supported from what I heard [10:28] Son_Goku: I think there's a thread about that actually [10:28] hm [10:28] Son_Goku: no, let's start one [10:28] the Rust forum uses social sign-on, I think [10:29] yeah, Rust uses GitHub [10:29] https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75 [10:29] one of the other ones I know of uses Google [10:29] Son_Goku: looks like the patch apply failed this time [10:30] :/ [10:34] ogra: https://forum.snapcraft.io/t/gardening-in-github-com-snapcore-core-build/76 [10:36] morphis: fixed the patch, but it didn't work [10:36] Son_Goku: you have the full patchset somewhere? [10:36] let me create the patch on top of that [10:38] morphis: the patch set is http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/ + https://da.gd/qUH4P [10:43] Son_Goku: https://paste.fedoraproject.org/paste/AFR94F40CNQwmk3eFcy4Rl5M1UNdIGYhyRLivL9gydE= should cleanly apply on top of the patchset [10:44] yes, but it still doesn't fix the problem [10:44] oh wait [10:44] la [10:44] zyga, if you mention me in the post you dont need to ping on IRC ;) [10:45] (was already writing an answer when you pinged) [10:46] ogra: aha, you get destkop notifications on @-mentions? [10:47] morphis: take 4: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679552 [10:47] zyga, yeah [10:49] Son_Goku: we're coming closer :-) [10:50] Son_Goku: ok, this didn't help [10:51] Son_Goku: need to scratch my head around this when I am done with my meetings [11:17] PR snapd#3113 opened: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap [11:30] Chipaca: you might want to look at snapd#3113 when one have a moment, it's not big, it's the changes about locking discussed yesterday [11:30] PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap [11:30] pedronis— looking [11:32] pedronis: yes, 3109 is mergable [11:32] zyga: sure, I have a look at the fstab thing [11:34] PR snapd#3109 closed: Merge 2.23.6 release back into master [11:35] mvo: done [11:35] zyga, https://github.com/snapcore/core-build/pull/1 [11:35] PR core-build#1: adjust README file to proper reflect repo content [11:37] pedronis: ta [11:38] ogra: +1 [11:57] pedronis— +1; lgtm and good start [11:58] Chipaca: care to do a 2nd review of https://github.com/snapcore/snapd/pull/3102 [11:58] PR snapd#3102: interfaces/mount: add function for parsing mount entries [11:58] zyga— nah [11:58] * Chipaca grins [11:58] Chipaca: et tu Brutus? [11:58] ;-) [11:59] zyga— et ideam habent quam multa. [11:59] morphis, Son_Goku: things will also get much better when we don't kill the process for a seccomp denial and instead return something like EPERM. this is in progress [12:00] jdstrand: yeah, that would help [12:00] jdstrand: however I still fear we will run into multiple bugs with just seccomp and no AppArmor [12:00] so having some extensive testing before we enable this would be good [12:01] morphis: the sandbox is definitely designed for both to be enabled. enabling seccomp without apparmor isn't really gaining you much [12:01] jdstrand: right [12:01] morphis: I mean, sure, you can't load a kernel module, but you can write a file to /etc/modules.d [12:01] jdstrand: so for other systems we need SELinux + Seccomp or nothing [12:02] /etc/modules-load.d [12:03] zyga— +1 (with a comment) [12:03] morphis: re selinux> yes, though selinux only has rudimentary dbus mediation compared to apparmor [12:03] jdstrand: yeah sadly, but this is something we need to talk in the near future [12:03] jdstrand: having this on my road map for cross-distro after I am through all the others things :-) [12:04] morphis: this was actually discussed a good bit in the Hague [12:04] jdstrand: FYI, overlayfs got good selinux support lately, is that because LSMs got improved or and so apparmor "groks" overlayfs automatically or is that selinux specific, do you know? [12:04] jdstrand: oh great, seems like I missed that session :-) [12:04] jdstrand: are there any notes available? [12:04] morphis: I suspect that the list of interfaces available will need to be different for an apparmor enabled system vs an selinux system [12:05] jdstrand: yeah, maybe [12:05] morphis: it was inconclusive. various problems were identified because of the capabilities of each system and how they both approach MAC differently [12:06] Chipaca: thanks for the hint, applied! [12:06] morphis: when you are starting to write selinux policy, you'll want to do a hangout with at least me, Tyler and jj [12:06] jdstrand: absolutely [12:06] zyga— as i said the compiler is probably good enough nowadays to not make it necessary, but sometimes (like here) it's probably clearer anyways [12:07] Chipaca: yeah, I really like it, feels pythonic in good way :) [12:07] :-) [12:07] jdstrand: this is currently somewhere on the horizon but I want to have proper CI for those systems in place first [12:07] zyga— yeah [12:07] morphis: I think you could start by trying to run unit tests on snapd build on fedora [12:07] morphis: that will show looooots of red because of /snap shift [12:07] zyga: yeah :-) === cachio_afk is now known as cachio [12:08] morphis: niemeyer suggested that we add a mock call so that those tests assume /snap is still in place [12:08] morphis: for spread you will need a different tactics I fear, as those are integration tests [12:08] morphis: it is possible to do things like: the process with this label can talk to the process with that label over dbus with selinux (eg, I can talk to all of network-manager or I can't talk to network-manager at all), but for carving out parts of the dbus api-- no [12:08] morphis: while not perfect, I had an idea with snapd-fhs package that puts a /snap -> /var/lib/snapd/snap symlink in place [12:08] zyga: yeah, mock call sounds good, will need to look into that once we're through the current phase of getting distros into shape [12:08] morphis: as a $0.01 solution [12:08] zyga: depends if we can that approved by the other distros [12:09] morphis: but there are other issues that aren't at the top of my head [12:09] (even with dbus) [12:09] jdstrand: are you sure? I saw some fine-grained mediation for dbus + selinux lately (but maybe I was confused) [12:09] morphis: for spread testing [12:09] morphis: not for anything else [12:09] jdstrand: I think we should come together at some point and just brainstorm to see what problems we have and to guess possible solutions [12:09] zyga: patches to dbus deamon? [12:10] zyga: flatpak uses a proxy for that, maybe they added selinux to that [12:10] jdstrand: I think to selinux, I saw policy language that was referring to specific methods [12:10] * zyga googles [12:10] if you're talking flatpak, they either write services where the whole api is safe or use a proxy [12:11]