Deprecating Linux support for #gentoo: https://www.gentoo.org/news/2026/04/01/gentoo-hurd.html
Remote
sam
@thesamesam@social.treehouse.systems
mastodon 4.6.7+glitch-th@gentoo@fosstodon.org developer. Spends a lot of time on alternative platforms.
643 Followers
438 Following
35 Posts
Joined December 12, 2022
Replying to
@mgorny Compare Solar Designer's attempt to find a compromise at https://www.openwall.com/lists/oss-security/2026/05/01/2 with the response at https://www.openwall.com/lists/oss-security/2026/05/01/3
I don't think I can keep commenting on this, because it's driving me mad. I've already tried to be very restrained in what I say.
Boosted by @hj@shigusegubu.club
Replying to
@pinskia @david_chisnall @edwintorok @regehr Our steve jobserver can do that (https://codeberg.org/gentoo/steve) I wouldn't expect ninja to implement it, at least any time soon.
Replying to
@pinskia @mgorny I've felt for a while that the GCC approach is quite reasonable because it's not so old that people forget big changes in a release. And remember, in GCC (and in basically every project but the kernel), the backports are either done by the person who made the change, or at least they are asked.
In the kernel, it is basically automated git cherry-pick. If it applies cleanly, in it goes. Doesn't mean it does the right thing. If not, good luck.
Replying to
@vbabka @tomasv @AndresFreundTec @mgorny ... yes, @grsecurity pointed out the CEO has stated they included a full exploit. Beyond words.
@alwayscurious@infosec.exchange Could you share a bit more detail on your wpa_supplicant thoughts? There's a lot of reevaluation of iwd right now and I'm interested in what you had in mind.
(re https://www.openwall.com/lists/oss-security/2026/05/01/12)
Replying to
@tomasv @AndresFreundTec @mgorny Yeah, I agree there. What I lobby for here is a "break glass" protocol for issues that are clearly more serious.
For the less serious cases: it depends on what we're talking about upgrading to: latest in that release series? Yes, I think that's fair.
If it's instead about upgrading to a newer kernel overall, then the LTSes probably shouldn't exist anymore. I appreciate not everything can be backported and that backporting has its own risks, just the calculus is different when you have some very common config option and trivially exploitable bug.
But in this case as discussed, there weren't backports available, and they only became available by luck and from heroic moves by Eric (unplanned).
Replying to
@anton@icosahedron.website @mgorny@social.treehouse.systems I love your articulation of point 1! It's something I say to people that it's the ultimate expression & practice of free software, being able to actually customise at-will.
Away from kernelposting finally..
I find Rust's LTO implementation curious in a few ways.
First, there's the very unfortunate term collisions with both LLVM and GCC [0].
But I find it interesting that they both somewhat advertise, and projects make use of, -C codegen-units [1], because you then don't get consistent results with LTO.
As far as I know, in LLVMland, nobody encourages you to mess with partitioning, and it seems like it'd be a better idea for Rust to work on partitioning instead so nobody would need to set it.
I see people recommend =1 quite often but needing to do that in GCC is basically unheard of (seen some very rare cases where it might have been useful), and I don't know if LLVM even has a strict equivalent.
[0] https://wiki.gentoo.org/wiki/LTO#Terminology
[1] https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units
Replying to
@Codeberg@social.anoxinon.de It'd be a good time to encourage folks to sign up to https://github.com/sponsors/Xe
Today, we changed the default recommended filesystem in the #gentoo handbook from ext4 to xfs.
XFS is robust and has all the niceties of ext4 (modulo shrinking) but with modern features on top.
(It helps that xfsprogs doesn't have weird endianness bugs too..)
btrfs is of course another option for the future but our users are conservative in some respects, and baby steps > none.
The main benefit of this is reflinks and copy_file_range which automatically takes advantage of that.
Now, as for using it.. 🧵
Why are Xen security issues allowed to retain their security marking in commit messages, like in https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.3 ?
Replying to
Replying to
@zwol@masto.hackers.town Thanks, someone else mentioned the other day as well that it looks like this is quite an old systemd requirement that they gutted about ~10 releases ago, I plan on handling that first but then auditing any of the other options in there.
Replying to
@tomasv @AndresFreundTec @mgorny This doesn't apply if the reporter has provided what seems to be a genuinely serious vulnerability or if they've provided a PoC, though. I'm not asking for in-depth analysis of every vague possible bug that people report.
Replying to
@lenary Thanks! Do you know if LLVM lets you customise the partition size (or amount of them), and whether it's just an internal parameter or whether it's documented as a user-facing option?
Replying to
@pinskia Thanks, I'll tweak that tomorrow (and maybe put it into a proper article at some point, not just on a wiki).
Replying to
@marix@chaos.social @tante@tldr.nettime.org We do self-host our own git, bugs, ... infra. We're just moving to codeberg for a place for people to send PRs if they wish, rather than github.
Replying to
@tante@tldr.nettime.org > but we can't just "move everything to Codeberg".
FWIW, we're not doing that (explained in another post), but we also went out of our way to very much ask for Codeberg consent and to make sure they were OK with the traffic :)
They were also very supportive. Your point is of course a good one in general though.
Replying to
@mid_kid@fosstodon.org @gentoo@fosstodon.org For ppc64, there's Raptor (https://www.raptorcs.com/) running on IBM servers, and also old Macs ofc.
Replying to
@sunfish See also: "in general" in mathematics (always true, no exceptions) vs English (mostly true, various levels of exceptions)
Replying to
@karolherbst @mgorny @fmoessbauer Right. It was assigned at https://lore.kernel.org/all/2026042214-CVE-2026-31431-3d65@gregkh/
Replying to on cosocial.ca
@mhoye@cosocial.ca Whole thing is frustrating in that the bloody bug in question was specifically a "good first issue" for a human so they could invest in a contributor, too.
Replying to
@alwayscurious@infosec.exchange Could you elaborate a little bit? If the answer is "go look around at and it is obvious" then fine, but wondering if you have some bits in mind?
I'm asking because it's a big change for me to start lobbying "internally" to push people away from iwd, and also because iwd itself was quite married in the past to its current approach.
wpa_supplicant on the other hand is an older codebase but it does support privilege separation, and does get actively developed; though it rarely makes releases, including for serious bugs or security issues, so backports are required.
But I've spent very little time looking at wpa_supplicant/hostapd's codebase other than when massaging some patches.
Replying to
Replying to
@karolherbst @mgorny @fmoessbauer > But also, there is no difference between security fixes and "normal" fixes besides there is a CVE entry for one and not the other 🙃
Stop receiving private reports and don't remove mentions of possible security impact in commit messages then?
Replying to
@tante This unfairly discriminates against the French, though ;)
I've never seen French Canadians do this which I don't understand.
Replying to
@King_of_Ooo@defcon.social @mgorny@social.treehouse.systems Many of the complaints people have with PGP don't really apply to the use that distributions have for it (like say, issues with metadata). minisign is okay but it recently had its C implementation abandoned for a Zig one.