2026-10-01 06:47:21 <ncopa> what is up with the selinux support added everywhere?
2026-10-01 06:50:05 <lotheac> not sure if you are referencing anything specific, but didn't you see the pmos selinux talk by achill and aelin?
2026-10-01 06:53:36 <ncopa> i didnt, sorry
2026-10-01 06:53:38 <Biswa96[m]> are recordings of those talks available somewhere?
2026-10-01 06:54:21 <lotheac> the idea was that pmos (nura) want selinux and most of that work is upstreamable to alpine
2026-10-01 06:54:54 <ncopa> https://pretalx.postmarketos.org/postmarketos-conference-2026/talk/8RZSQ9/
2026-10-01 06:55:01 <ncopa> was on sunday aw
2026-10-01 06:55:43 <lotheac> or maybe not "most", but anyways - the costs were negligible in terms of package size, the biggest one was having to link libselinux
2026-10-01 06:56:18 <lotheac> according to the talk anyway, i didn't check myself :)
2026-10-01 06:56:26 <ptrc> Biswa96[m]: they will be at media.ccc.de most likely, we’ll post about this on #conference:postmarketos.org and in a few other places as well
2026-10-01 07:01:54 <ncopa> i dont know if things has changed, but it used to be painfully complicated
2026-10-01 07:02:33 <ncopa> and implementation also
2026-10-01 07:13:37 <aelin> that iproute2 MR and openssh are the last two packages that need changes in aports for now
2026-10-01 07:14:06 <aelin> I'll make sure to only build the -pam variant of openssh against libselinux so that more minimal installs aren't affected
2026-10-01 07:14:58 <ptrc> that + the lib is like ~100k anyway and a no-op on non-selinux systems
2026-10-01 07:17:37 <aelin> with all that done, one can boot a minimal Nura install with enforcing SELinux and we wouldn't have to keep any forks downstream, that'd be very nice :)
2026-10-01 07:51:41 <ncopa> i am worried about the long term maintenance
2026-10-01 08:17:18 <achill> what exactly is worrying? ofc we will maintain selinux in alpine incl. packages and the linking against the packages
2026-10-01 08:25:04 <qaqland> imo, we should open an issue in alpine to describe the change and track the progress, like usr/merge did?
2026-10-01 09:27:08 <ncopa> the problem is that once we add this, and users start using it, it will be close to impossible to remove again
2026-10-01 09:28:11 <ncopa> what I worry about is that we now think this may look like a good idea, we start implement it, and later on realize that it costs to much, and maintainers back off
2026-10-01 09:28:15 <ncopa> and it land on me
2026-10-01 09:28:31 <ncopa> or the package maintainers, who never signed up for it
2026-10-01 09:29:10 <ncopa> selinux is not the simplest solution to the problem, which is why we have avoided it since the beginning
2026-10-01 09:30:20 <ncopa> if there is a bug related to selinux, who will spend the time to find out if the problem is policy related, bug in libselinux or in the tool itself? who is responsible for investigate?
2026-10-01 09:30:32 <ncopa> if we link libselinux, will users expect that it works?
2026-10-01 09:30:40 <ncopa> should they expect that it works?
2026-10-01 09:30:55 <ncopa> building and actually working are different things
2026-10-01 09:31:12 <ncopa> so if we end up being responsible that it works, who is responsible for testing it?
2026-10-01 09:31:42 <ncopa> selinux is also pretty intrusive
2026-10-01 09:32:30 <ncopa> and if there are any bugs related, will the bug be classified as security bug, and will require higher priority?
2026-10-01 09:33:08 <ncopa> should alpine be responsible for the policies?
2026-10-01 09:35:57 <ncopa> once this land in alpine, someone will have to support it for an eternity
2026-10-01 09:36:23 <ncopa> someone has to take responsibility for it
2026-10-01 09:37:13 <ncopa> not for an individual packages/dependency, but for the entire selinux/alpine story
2026-10-01 09:39:57 <ncopa> i am worried someone will eventually find out that this was complicated, and not so fun any more, and back out
2026-10-01 09:46:00 <ikke> The Nura developers take responsibility
2026-10-01 09:50:41 <omni> I resonate with those worries and had similar thoughts when this started to show up
2026-10-01 09:51:13 <omni> I also thought about dependency creep, but thought the added libselinux looked small and merged a couple of them
2026-10-01 09:53:52 <ncopa> is the plan to also enable selinux in busybox?
2026-10-01 09:53:59 <ncopa> I have no idea what the plan here is
2026-10-01 09:54:24 <ikke> selinux does not work well with busybox (single binary, multiple purposes)
2026-10-01 09:56:10 <ncopa> as I said, i have no idea what the plan here is, but I know I personally dont want to deal with selinux
2026-10-01 09:56:18 <ncopa> speaking of responsibility
2026-10-01 09:57:00 <ncopa> achill: do you have any plans to follow up on this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104180 if not, should I close it?
2026-10-01 09:57:45 <ncopa> we also need help with someone take over maintainership of linux-stable. I have more than enough with linux-lts
2026-10-01 09:58:10 <Caseyshethey[m]> ncopa: ikke: we would also switch to coreutils + bash i believe
2026-10-01 09:58:26 <craftyguy[m]> we == nura/downstream
2026-10-01 09:58:27 <ncopa> we as in alpine or nura?
2026-10-01 09:58:44 <Caseyshethey[m]> nura XD
2026-10-01 10:01:57 <Caseyshethey[m]> ncopa: dbus at least is already built against libselinux since a few weeks ago https://gitlab.alpinelinux.org/alpine/aports/-/commit/7381654e2de475273b6a5bce679f42b974d3b4b3
2026-10-01 10:02:36 <ncopa> do we have any work item about supporting selinux i alpine? anything in written that can be used as documentation that you (nura) aagree to take reponsibility for everyting related selinux?
2026-10-01 10:02:44 <ncopa> i saw there are a bunch of those
2026-10-01 10:03:00 <ncopa> git log --grep selinux
2026-10-01 10:04:44 <ncopa> util-linux, sudo, shadow, procps-ng, psmic, findutils, coreutils, dbus, networkmanager, linux-pam in last month
2026-10-01 10:05:42 <ncopa> 197c8e829059641e2ee70dc23bf1ecd61d3d3057 which can be interpreted as alpine is all in selinux
2026-10-01 10:07:13 <Caseyshethey[m]> ncopa: i might have missed something but i don't think nura have committed to selinux, considering the complexity and breadth of it i expect that decision will go through the pmcr process, so there's space to discuss it and address concerns and risks and account for issues in the plan
2026-10-01 10:10:57 <ncopa> well, i surely would have appreciated if someone at least would have asked my opinion before making alpine go all in selinux
2026-10-01 10:18:11 <ncopa> so, the dilemma I currently have: I need to get builders for 3.25 up ASAP, i need find someone take over linux-stable or decide if we delete it
2026-10-01 10:18:45 <ncopa> if we do alpine 3.25 with selinux enabled all the way, we risk that we will have to maintain it for ever
2026-10-01 10:19:09 <achill> re Linux stable, I'm gonna look at it at saturday
2026-10-01 10:19:54 <achill> re selinux, as said in the talk, it's just like any other library we optionally enable on request. the only difference is that it affects more packages imo
2026-10-01 10:20:13 <achill> sorry for not talking to you or making that clear for alpine side of things
2026-10-01 10:20:21 <achill> that is on me, I just assumed
2026-10-01 10:20:55 <ncopa> i guess my point here is that selinux is more than just another library
2026-10-01 10:21:17 <achill> I mean the things we do in alpine, is just treat libselinux like any other lib
2026-10-01 10:21:25 <achill> we didn't to anything further in alpine
2026-10-01 10:21:40 <achill> the "all in selinux" was me giving up on app armor, because I maintained it
2026-10-01 10:23:41 <ncopa> yeah, i understand that you mean yourself, not alpine. im not sure people from outside will understand that when reading git log
2026-10-01 10:24:23 <achill> hm yeah I guess
2026-10-01 10:26:37 <f_>  11:58 <Caseyshethey[m]> ncopa: ikke: we would also switch to coreutils + bash i believe
2026-10-01 10:26:38 <f_> huh
2026-10-01 10:26:50 <f_> The idea with busybox is to build busybox ash separately
2026-10-01 10:26:56 <f_> then selinux would work properly
2026-10-01 10:28:15 <f_> GNU coreutils are also being compiled as a single binary: lrwxrwxrwx 1 root root 9 Mar 12  2026 /usr/bin/cat -> coreutils
2026-10-01 10:30:30 <f_> This is something I want to do, btw. I think it would be doable by simply in the busybox package, building busybox with just ash enabled and nothing else, and distribute it as busybox-ash, which would be installed by default
2026-10-01 10:31:16 <f_> it would also allow people to uninstall ash if they don't want it
2026-10-01 10:31:48 <f_> And as far as I understood from asking during the talk it would make busybox work with SELinux
2026-10-01 10:35:20 <ncopa> achill: can I close https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104180?
2026-10-01 10:35:36 <achill> ah yes
2026-10-01 10:37:02 <achill> would love to do it but should probably after I have at least some coordination between studying and working on alpine :p
2026-10-01 10:37:29 <ncopa> yeah, i know
2026-10-01 10:38:40 <ncopa> re selinux, as I understand, there are currently on intention for alpine to maintain any selinux policies, right?
2026-10-01 10:39:32 <f_> afaik they just use fedora policies with adjustments for alpine?
2026-10-01 10:39:41 <f_> at least from what I understood in the talk
2026-10-01 10:39:59 <ncopa> ok, maybe i should wait til the talk is out and watch it
2026-10-01 10:40:26 <ncopa> what is not clear is: who maintains those policies and are reponsible for them
2026-10-01 10:41:54 <ncopa> if it is nura, then alpine is basically shipping functionality (and are responsible for the maintenance of it) that we don't test or use at all
2026-10-01 10:43:40 <ncopa> the core packages gets new hard dependencies (apparently some supports dlopen)
2026-10-01 10:43:46 <achill> ncopa: yes testing/fedora-policy is the policy we adjusted for alpine. we didn't test it against alpine itself, but I expect it to be very similar to nura. most changes to the fedora policy are like file paths or newer versions
2026-10-01 10:44:07 <achill> also afaik some people also want to try out SELinux on alpine itself
2026-10-01 10:44:55 <achill> yea some core pkgs, like linux-pam get a dep with 100kb. that's the "downside"
2026-10-01 10:44:57 <ncopa> i dont doubt people want to try it out. problem is once we enable it we cannot disable it
2026-10-01 10:45:06 <achill> moving it to dlopen would be cool
2026-10-01 10:45:54 <achill> ncopa: at least we shouldn't. breaking changes between versions are fine if communicated as such. but yeah, we plan to maintain it long term for alpine and nura
2026-10-01 10:46:44 <ncopa> its not so much about the 100k its about everything around it
2026-10-01 10:47:11 <achill> but what is there around it? the policy itself is in testing/.
2026-10-01 10:47:52 <ncopa> if there are any vulnerabilities in libselinux, libsepol, libsemanage (even if this is unlikely), alpine users who never uses those features will be affected
2026-10-01 10:48:57 <ncopa> alpines current selling point for security is low attack surface due to not add unecessary dependencies
2026-10-01 10:50:24 <achill> hm I guess so, but libselinux is very much a no op on a non selinux system. the attack surface is tiny imo
2026-10-01 10:51:57 <ncopa> when users will se libselinux pulled in as dep it is not unreasonable of the to believe that selinux is supported
2026-10-01 10:53:06 <ncopa> it is also a part of the bootstrap chain (probably not that big problem, but it adds up)
2026-10-01 10:54:18 <ncopa> the main problem is that you cannot uninstall or remove functionality we don't use. its if its only 100k, its still dead C meat.
2026-10-01 10:54:39 <ncopa> and that is also the reason why I never liked selinux. the way it is implemented is intrusive
2026-10-01 10:55:23 <ncopa> and yes, selinux was considered back in the days when security was more a central thing in alpine
2026-10-01 10:58:30 <achill> yeah at the conf, nmeum and others were interested in doing something like libselinux but different, basically "made for alpine". but we dont live in that ideal world where we have time to work on that unfortunatlely
2026-10-01 11:01:36 <ncopa> the security argument (unecessary deps) are more real than I first thought
2026-10-01 11:02:16 <ncopa> those are the things that would affect us, even if we never use the selinux feature: https://app.opencve.io/cve/?product=pcre2&vendor=pcre
2026-10-01 11:05:16 <ncopa> and fixing the CVEs would be more complicated than just bumping pcre2. it is not obvious but lvm2 and device-mapper would need a rebuild as well. db3446e8011261303d367f5310d00079eaa9ffca
2026-10-01 11:05:20 <ncopa> 5810c92eac4b8cd1a817d5d8d8f64bc3a1f589db
2026-10-01 11:07:02 <ncopa> so it does come with a maintenance cost for alpine + increased risk and no clear benefit at all for alpine
2026-10-01 11:07:39 <ncopa> i find it difficult to get the cost/benefit calculation justify adding selinux in alpine
2026-10-01 11:09:31 <andar1an[m]> Is it currently not possible to enable selinux yourself? I went apparmor route, bases on discussion it seems selinux can't be setup in alpine? Or is this about making selinux available by default?
2026-10-01 11:10:18 <ncopa> this is about making it possible to enable selinux
2026-10-01 11:10:42 <ncopa> i am sorry if I am negative or harsh, but I need to be able to defend this change to the larger alpine community
2026-10-01 11:12:13 <ncopa> i need to be able justify for a million docker users why they suddenly have pcre2 vulnerabilities to fix due to a feature they never use asked for
2026-10-01 11:13:58 <andar1an[m]> Socratic method, It's a good one.
2026-10-01 11:13:58 <andar1an[m]> What is the blocker for a user enabling themselves? Busybox? Is there a pathway where a guide to setting up is a valid option as opposed to changing Alpine?
2026-10-01 11:17:30 <ncopa> the problem is that you need to link everyting with libselinux, you get a new hard dependency pulled in. everyone gets it regardles if they enable the feature or not
2026-10-01 11:17:55 <andar1an[m]> Could one have a specific kernel for selinux users?
2026-10-01 11:18:40 <andar1an[m]> linux-se lol and a aubset of -se packages? Lol
2026-10-01 11:18:45 <andar1an[m]> Prbly dumb
2026-10-01 11:19:26 <andar1an[m]> But it could potentially isolate selinux specific packages from larger community
2026-10-01 11:19:33 <ncopa> it is the userspace libraries in this case. I think we have selinux built in to the kernel already IIRC
2026-10-01 11:20:08 <ncopa> no, its not
2026-10-01 11:20:14 <ncopa> we dont even have in the kernel
2026-10-01 11:20:24 <ncopa> so you could not use it even if you wanted
2026-10-01 11:20:28 <andar1an[m]> so maybe having a specific version of userspace libs with -se?
2026-10-01 11:20:43 <ncopa> yeah
2026-10-01 11:21:07 <ncopa> separate user space packages is one way to do it
2026-10-01 11:21:33 <andar1an[m]> And i guess a linux-se kernel too as you stated not enabled
2026-10-01 11:22:56 <andar1an[m]> I imagine that would not be a ubiquitous hardenned kernel though if you don't use selinux?
2026-10-01 11:24:40 <ncopa> not sure what you mean. MAC and hardening the kernel are different things
2026-10-01 11:33:57 <andar1an[m]> I mean if you were creating a separate kernel for selinux, it wouldn't be one that is also necessarily hardenned
2026-10-01 11:37:02 <andar1an[m]> Unless that was an explicit choice due to overlap of concerns? But that would mean people wanting to use a hardenned kernel are required to have selinux enabled even if don't use. So was just trying to explicitly delineate
2026-10-01 11:37:50 <andar1an[m]> I guess i should say users, not people. Bota have choices too :joycat:
2026-10-01 11:37:59 <andar1an[m]> s/bota r/bots
2026-10-01 12:48:46 <aelin> ncopa: we explicitly don't try to patch OpenRC or busybox so that barebones installs can get away without pulling in libselinux, but I guess if Alpine wants to decide to support SELinux then that would have to be done as well
2026-10-01 12:50:04 <ncopa> ok
2026-10-01 12:50:13 <aelin> achill and me will maintain testing/selinux-policy for the foreseeable future and we have done the necessary enablement on the Nura side
2026-10-01 12:51:24 <aelin> I'm happy to also look into the OpenRC and busybox side of this, but I figured Alpine officially supporting this would be a bit of a larger step than just "we'll link a few binaries against this that are not essential" 
2026-10-01 12:51:42 <ncopa> is this just for testing it out for now, or is it decided and the plan ahead?
2026-10-01 12:52:11 <ncopa> i guess i have to watch the video when it comes out for those answers
2026-10-01 12:52:20 <ncopa> libselinux is more than 100k btw
2026-10-01 12:52:25 <aelin> it's 160K yeah
2026-10-01 12:53:05 <ncopa> it also pulls in pcre2 and musl-fts so 966 kb in total on x86_64
2026-10-01 12:53:29 <aelin> our plan is to make SELinux opt-in on mutable Nura installs and enabled by default in immutable builds
2026-10-01 12:53:52 <aelin> and "we" in this context is achill, craftyguy[m] and me
2026-10-01 12:53:57 <ncopa> alpine does not even have selinux enabled in kernel, so this does not bring alpine any benefit at all
2026-10-01 12:54:12 <aelin> correct
2026-10-01 12:54:27 <aelin> it would lay the groundwork for Alpine later supporting it if you choose to
2026-10-01 12:54:41 <aelin> we use our own kernel packages in Nura where we enable it
2026-10-01 12:54:59 <aelin> but we want to avoid forking packages where we can
2026-10-01 12:55:21 <aelin> I'm happy to chat about this in a call sometime if you'd be down for that
2026-10-01 12:55:36 <ncopa> i'd be happy to
2026-10-01 12:55:47 <ncopa> probably not this week though
2026-10-01 12:56:07 <aelin> we're not in a hurry ^^
2026-10-01 12:56:26 <achill> 👍
2026-10-01 12:56:51 <ncopa> i kinda am. i want to have a decision what the road ahead is before 3.25. and i was supposed to work on the builders today
2026-10-01 12:57:23 <f_> It doesn't have to be chosen by 3.25 I think?
2026-10-01 12:57:35 <ncopa> i dont want to link in libselinux unless there is a concrete plan for turning alpine into an selinux distro
2026-10-01 12:58:01 <ncopa> it will be difficult (impossible?) to revert once we link stuff in and people start use it
2026-10-01 12:59:15 <achill> again, we can revert it when communicating correctly, if we decide to unlink all packages again
2026-10-01 12:59:29 <ncopa> before 3.25 is out, yes
2026-10-01 12:59:32 <achill> this should probably be a tsc issue, but well
2026-10-01 12:59:37 <ncopa> yeah
2026-10-01 12:59:39 <ncopa> it should
2026-10-01 12:59:46 <achill> no also after that, we do it a dozen of times
2026-10-01 12:59:52 <achill> we do breaking changes
2026-10-01 12:59:56 <achill> and that is fine
2026-10-01 13:00:04 <f_> doas apk fix tsc
2026-10-01 13:00:08 <ncopa> not within a stable branch
2026-10-01 13:00:26 <ncopa> best case we have to live with it for two years
2026-10-01 13:00:38 <achill> I mean yeah, but I can assure we're going to maintain the 3.25 branch for SELinux
2026-10-01 13:00:42 <ncopa> if its included in 3.25 and deleted afterwards
2026-10-01 13:07:49 <ncopa> other option would be to have dual builds of those packages. coreutils-se and coreutils
2026-10-01 13:07:59 <ncopa> and you pick the flavor you want
2026-10-01 13:08:48 <achill> tbh this is just worse, i'd rather not do selinux than this
2026-10-01 13:08:52 <achill> dlopen() would be ideal
2026-10-01 13:08:59 <achill> but we'd need to do more work and convince upstreams
2026-10-01 13:10:26 <ncopa> dlopen is not perfect either. you cannot catch ABI breakages easily
2026-10-01 13:10:35 <Sertonix[m]> dlopen would make systems using regular apk upgrade flaky due to not representable soname constrains
2026-10-01 13:10:55 <ncopa> at this point breaking ABI in libselinux would be bad though, so it is unlikely i guess
2026-10-01 13:11:40 <Sertonix[m]> Do they have an ABI policy?
2026-10-01 13:15:38 <achill> pretty sure theyre not going to break abi
2026-10-01 13:15:45 <achill> idk if they have a specific policy for that
2026-10-01 13:15:49 <achill> but its very unlikely
2026-10-01 13:17:19 <achill> but i also dont really have time to chitchat about selinux, if you have specific concerns we can discuss them, ideally in a call or so. i'll try to write a issue (hopefully saturday) about what were doing in alpine to support selinux, and how much we support it etc etc.
2026-10-01 13:28:15 <omni> what? !108993 was merged without ncopa having a say?!
2026-10-01 13:28:35 <omni> it sems to me like the selinux changes should be reverted until at least after 3.25-release
2026-10-01 13:43:34 <ncopa> yeah, i think we should revert til after 3.25 atleast, and then find out what to do with it
2026-10-01 13:48:01 <ncopa> how many users do you expect to use it? do you have anything indicating that this is something a majority would actually use? is the long term plan to make selinux enabled by default and allow people opt-out?
2026-10-01 14:03:13 <achill> we dont have any numbers, but the propsal for nura is to use it on our immutable-variant (the one we will recommend for end-users)
2026-10-01 14:03:21 <achill> many people were interested in MAC after the talk, from nura devs as well from alpine devs. i expect a working MAC implementation in alpine generally something alpine users would appreciate (espeically because were simple small and secure).
2026-10-01 14:03:30 <achill> for nura immutable the goal is opt-out. but for nura mutable and all of alpine, the goal is opt-in. e.g. i personally still want non-selinux on my dev machine :p
2026-10-01 14:03:32 <achill> reverting for 3.25 sounds good to me!
2026-10-01 14:08:28 <andar1an[m]> Nura is new name for pmos?
2026-10-01 14:08:31 <f_> yes
2026-10-01 14:08:46 <andar1an[m]> Cool
2026-10-01 18:55:00 <Sertonix[m]> PureTryOut: I opened MRs on kimageformats upstream to fix all the big-endian issues coverd by tests. Can we use them to re-enable kimageformats on s390x?
2026-10-01 19:24:17 <tonymet> anyone else getting checkpointed by go-away on gitlab.alpinelinux.org https://gitlab.alpinelinux.org/alpine/infra/infra/-/work_items/10878 
2026-10-01 19:29:22 <quinq> (not me at this time)