Post #2593012
2026-04-30 03:07 UTC
@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".
Replies (1)
-
@equinox@chaos.social 2026-04-30 03:19
@dalias@hachyderm.io @mirabilos@toot.mirbsd.org oh I totally agree. My AF_ALG code comes with an equivalent openssl implementation that is bit compatible. It just doesn't support the primary secret being moved into kernel memory (or TPM). (I test my code on FreeBSD, not everything, but anything that may have OS deps. Testing random Linux permutations is a bit much, but if it works on FreeBSD that should cover a lot)