On Wed, Feb 04, 2026 at 09:42:17AM -0500, Andrew Cagney wrote: > > > > Yes we should probably fix this. I am not sure if anyone uses queries. > > At least one project is :-) > > > I'm pretty certain iked doesn't but isakmpd might. > > > > Not sure how useful it is to have queries in an implementation that > > already diverged quite a lot from all the others, but that is another > > discussion I guess. > > The only divergence I know about for SADB_REGISTER is that OpenBSD > includes SADB_X_EXT_SUPPORTED_COMP in its response. > > I find having the kernel announce what it supports acts as a friendly > heads up that a new mysterious algorithm has been added, or some cruft > has finally been deleted. > > One alternative is to try installing an SA with each algorithm, it > works better when the crypto is in a yet-to-be-loaded kernel module, > but misses new algorithms.
Makes sense. I was just asking because apparently no one tried in using it for a while. If it helps you I'll see if I can fix it. > > > CHACHA should also work. It might be easier to check existing users > > of the API. In iked that would be: > > https://github.com/openbsd/src/blob/master/sbin/iked/pfkey.c#L75-L95 > > I suspect NONE/NULL (can never remember which) is also missing from > the integrity table. Looks like we are sending NONE in iked (by simply not initializing the field) rather than an explicit NULL. We don't even have AALG_NULL defined it seems. Looking at NetBSD and FreeBSD both have NULL in their supported list so I guess that is what we would want too. Does libreswan actually send AALG_NULL for AEADs or just leave the sadb_sa_auth field empty like iked does? I am wondering whether it would be enough to announce support for NULL or if we also need logic to map them on the kernel side. > > Thanks
