2026-10-01 10:41:28 <omni> the test_site test is failing in !109022 and I worry that it is an indication that something is broken in 3.24-stable
2026-10-01 10:41:33 <omni> but idk
2026-10-01 11:16:00 <omni> oh, hey, it passed after I got the pcre2 security upgrde in, cool
2026-10-01 11:16:53 <dne> hm
2026-10-01 11:18:58 <ncopa> since this is the security channel, do you think is supporting selinux is worth it?
2026-10-01 11:19:00 <omni> or am I just making wild assumptions? 
2026-10-01 11:20:32 <omni> ncopa: I have similar feelings and concerns as the ones you have raised, and I've personally never bothered with selinux due to its complexity
2026-10-01 11:22:09 <ncopa> my question here is if we want to support it properly
2026-10-01 11:44:46 <jvoisin> I think it would be _a lot_ of work
2026-10-01 11:44:53 <jvoisin> sam_: ^
2026-10-01 11:52:15 <invoked> ncopa: my pov, the decision is to make alpine a selinux distro, not a user choice really. you'd have to rework the tree
2026-10-01 11:53:19 <invoked> i guess you could make it a choice but it would be better to go all in on it, if that's what people want
2026-10-01 11:54:37 <durrendal> It sounds like it is what a small subset of peoplr want, but that it was not discussed openly in an Alpine oriented manner.
2026-10-01 11:54:41 <jvoisin> given that Alpine is ~mostly used in container, I'm not sure it's worth the effort
2026-10-01 11:54:44 <ncopa> i think that is the problem at hand. selinux is not really something you meaningfully can implement as an opt-in thing
2026-10-01 11:56:10 <ncopa> git log --grep selinux shows some activity enabling it. I wonder if we really want go all in, and turn alpine into a selinux distro
2026-10-01 11:58:34 <durrendal> What was the technical reasoning against apparmor? It's less intrusive and gets some of the same benefits as selinux without the hard dependency across the stack.
2026-10-01 11:59:09 <durrendal> It's not all the same benefits, but it's modular rather than what selinux is
2026-10-01 11:59:50 <ncopa> there was a talk about it last Sunday on the postmarketOS/alpine conference in Aachen. Unfortunately I could not attend Sunday so I am waiting for the video
2026-10-01 11:59:52 <jvoisin> durrendal: AppArmor is a tad useless unfortunately, in my experience
2026-10-01 12:00:12 <invoked> it will cause a lot of stuff to break. there will be pain
2026-10-01 12:00:26 <invoked> (until you figure it out)
2026-10-01 12:01:11 <durrendal> jvoisin: sorry, could you elucidate on that? I have professional experience with both systems, they work when implemented well and neither is useful if done poorly.
2026-10-01 12:02:00 <jvoisin> I have only seen a single public case of AppArmor blocking an exploit
2026-10-01 12:02:17 <durrendal> ncopa: I thought the TSC made distro wide technical decisions not individual groups of maintainers
2026-10-01 12:02:21 <jvoisin> AppArmor had trivial bypassed (that were burned by jann horn, RIP) for years
2026-10-01 12:02:56 <jvoisin> and I guess it's because Android is making pervasive use of it, but a lot of people are complaining about SELinux from an exploitation point of view
2026-10-01 12:03:46 <jvoisin> the Debian-shipped rules for AppArmor are usually super-duper-broad
2026-10-01 12:04:39 <jvoisin> and on a personal level, exploit-wise, AppArmor can and is usually simply ignored/bypassed :P
2026-10-01 12:06:54 <ncopa> durrendal: they are supposed to. but the TSC is currently broken
2026-10-01 12:10:36 <invoked> my deeper experience with selinux was with joshua brindle (gentoo) in like, 2003. :)  i'm sure it's better now, and you can reuse a lot of work other distros have done.  but i'm also sure it would still be a ton of work
2026-10-01 12:11:22 <invoked> maybe the reason you're hearing about selinux more is because people are extra paranoid with all the vulns.
2026-10-01 12:11:38 <invoked> tradeoffs: it would definitely make alpine harder to tinker with
2026-10-01 12:12:01 <durrendal> jvoisin: sure because apparmor is path based mostly, selinux does a lot more. Both just get worked around when implemented poorly.
2026-10-01 12:12:43 <durrendal> I don't think it's not worth doing, but I would love to see what that work looks like outside of the branch that becomes 3.25 so that we aren't breaking user space.
2026-10-01 12:14:27 <durrendal> ncopa: understood. A power vacuum is always filled, regardless of reason. If it is a problem that people operate this way then structure is needed.
2026-10-01 12:17:10 <durrendal> invoked: I'm not personally so concerned with difficulty to tinker, more so about what gets shipped to a user. Do I need to adjust complex systems like cloud-init? In so doing will it change the user's understanding of how that works? Who is writing these policies, or are we just assuming whatever fedora ships works? What are maintainers expected to adjust to to ensure their
2026-10-01 12:17:12 <durrendal> packages actually work on every bump and release?
2026-10-01 12:17:43 <invoked> > who is writing these policies
2026-10-01 12:17:46 <invoked> best question
2026-10-01 12:18:11 <durrendal> Without some level of distro level coordination and support this is the tail wagging the dog. It's not a bad change, it has good technical merit, but it needs more than just enthusiasm 
2026-10-01 12:19:56 <invoked> my feeling is that this year, i'm seeing across projects a lot of burn out. i dunno how people here are doing, but selinux will test people :)
2026-10-01 12:20:46 <invoked> even after, you know, you figure out all the major breakage in the first phase, it will be significant added work to maintain
2026-10-01 12:23:35 <durrendal> indeed, and I don't think complexity can't be overcome with real coordination and buy in. But I'd need to see a map, and a reason before Id 
2026-10-01 12:23:52 <durrendal> be convinced. A working example of the end goal (even of imperfect) goes a long way. 
2026-10-01 12:47:29 <ncopa> right now libselinux has just been linked in to a bunch of the core packages, for downstream. we dont even have selinux enabled in any kernels
2026-10-01 12:47:40 <ncopa> so its just dead meat for us
2026-10-01 12:51:30 <invoked> you could have selinux operating in permissive mode for a year or something, but it should be clear to everyone when you will switch it to enforce by default
2026-10-01 12:51:58 <invoked> or maybe you never do that. i dunno
2026-10-01 12:59:02 <ncopa> for now it just brings in pcre2 cves for no reason at all
2026-10-01 13:02:40 <invoked> jits are a problem overall tho
2026-10-01 13:03:20 <ncopa> so maybe not best idea to have it as a hard dependency for the core packages that you cannot opt-out?
2026-10-01 13:06:47 <invoked> imo you do it and you enforce by default (eventually) or, don't bother.  ok, i'm done wagging the dog. :)
2026-10-01 16:44:21 <invoked> omni: arti secfixes on the way https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4455