this time targetting ABI level 3; partially based on how claudio@ handled it in rpki-client. Fun how this bit of code has come full circle (gmid inspired what I wrote for got, which inspired what was written for rpki-client, which has come back.)

gmid (like all other daemons that want to do privsep crypto) has a very close relationship with libtls and need to stay in sync with it. OpenBSD' libtls was recently changed to use OpenSSL' EC_KEY_METHOD instead of the older ECDSA_METHOD, on the gmid side we have to do the same otherwise failures happens at runtime. In a similar manner, privsep crypto is silently broken in the current libretls (next version should fix it.) The proper solution would be to complete the signer APIs so that applications don't need to dive into the library' internals, but that's a mid-term goal, for the immediate bundling the 'little' libtls is the lesser evil. The configure script has gained a new (undocumented for the time being) flag `--with-libtls=bundled|system' to control which libtls to use. It defaults to `bundled' except for OpenBSD where it uses the `system' one. Note that OpenBSD versions before 7.3 (inclusive) ought to use --with-libtls=bundled too since they still do ECDSA_METHOD.

strnvis originates on OpenBSD. When NetBSD added it to their libc they decided to swap the argument. Without starting a holy war on the "best" argument order, adding an implementation of a function that's widely available and making its signature purposefully incompatible is beyond justification. FreeBSD (and so macos too?) followed NetBSD in this, so we end up with *two* major and incompatible strnvis implementations. libbsd is in a limbo, they started with the OpenBSD version but they'll probably switch to the NetBSD version in the future. That's why we can't have nice things. Do the right thing(tm) and check for the presence of the original strnvis(3), if not available or broken use the bundled one.

now it resembles less oconfigure and more the configure scripts I'm using in my recent projects. I'd argue it's more easy to use it.

it reached a point where this stuff is not maintenable. I'd like to move forward with gmid, but the restriction of capsicum and the linux environment at large that make landlock unusable (how can you resolve DNS portably when under landlock?) -and don't get me started on seccomp- makes it impossible for me to do any work. So, I prefer removing the crap, resuming working on gmid by cleaning stuff and consolidating the features, improving various things etc... and then eventually see how to introduce some sandboxing again on other systems. Patches to resume sandboxing are, as always, welcome!