Post #2593011

2026-04-30 02:56 UTC

@mirabilos@toot.mirbsd.org sure, if that's your choice then that's your choice. I have written code for AF_ALG and I run IPsec. (without ESNs, because that's the default in StrongSwan, and I haven't had reason to worry about rekeying.) I know who @dalias@hachyderm.io is and I greatly respect them for their work on musl. But I'll stick with my opinion until someone claims at least the same experience level as I have. Maybe that's dalias, maybe not, idk their skills on this.

Replies (3)

@dalias@hachyderm.io 2026-04-30 03:07

@equinox@chaos.social @mirabilos@toot.mirbsd.org Disabling AF_ALG does not prevent the kernel crypto primitives from being used in kernelspace; it just omits the userspace API for them. I'm not sure how the IPsec software stack is setup, but I've long been in the IPsec-haters club, so I can't say that's something I'd be worried about. Ultimately, if you want to use AF_ALG, I'm not stopping you, but I really wish folks would stop being like "oh, my software is Linux-only and Linux has AF_ALG, so it's fine to use it". Some of us disable kernel functionality that's gratuitous attack surface and that portable software can't use (because it's Linux-specific) and it's very frustrating when programmers are like "you need to expose yourself to more attack surface to use our stuff because we couldn't be bothered to just do things the right way calling library code in userspace".

Open ##2593012
@mirabilos@toot.mirbsd.org 2026-04-30 12:56

@dalias@hachyderm.io @equinox@chaos.social ok, I don’t run IPsec ;) (tried in a lab, once; decided on OpenVPN)

Open ##2593015
@equinox@chaos.social 2026-05-07 21:08

@mirabilos@toot.mirbsd.org @dalias@hachyderm.io surprise! the AF_ALG / algif_aead code is essentially "innocent". (=> dirty.frag)

Open ##2593016