instead of making things more obscure via gmid_strnvis(), let's
just check for strnvis with -Werror so we can swap the OS broken
implementation with the bundled OpenBSD one.
the previous -Werror triggers too easily: on NixOS for example the
FORTIFY_SOURCE #warning about a missing optimization level breaks all
the checks when using -O0 (which is the default for non-release builds).
so that we don't have to hardcode /etc in gmid.c. Helps on systems
like FreeBSD where the non-base programs are expected to look for
their config in /usr/local/etc.
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.
Set a sane default for INSTALL, allow it to be changed either as
environment variable or configure argument, and propagate it correctly
to the generated config.mk.
Issue reported by xavi, thanks!
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.
it's better than the previous Makefile.depend approach since this
automatically adapts to the included headers without requiring
manual intervention to regen the list.
It uses the 'common' proc.c from various OpenBSD-daemons.
gmid grew organically bit by bit and it was also the first place where I
tried to implement privsep. It wasn't done very well, in fact the
parent process (that retains root privileges) just fork()s a generation
of servers, all sharing *exactly* the same address space. No good!
Now, we fork() and re-exec() ourselves, so that each process has a fresh
address space.
Some features (require client ca for example) are temporarly disabled,
will be fixed in subsequent commits. The "ge" program is also
temporarly disabled as it needs tweaks to do privsep too.
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!
Both Linux and OpenBSD have LOGIN_NAME_MAX available when including
limits.h, FreeBSD, Darwin and possibly others don't.
FreeBSD (and maybe Darwin) have MAXLOGNAME, so try to use that if
available. Otherwise use _POSIX_LOGIN_NAME_MAX, but only has a fallback
since it has a lower value (9 at the time of writing).
If everything fails, use 32 which is what OpenBSD use by default;
OpenSMTPd also defaults to it.
(compat copied from kamid.)
Omar Polo
Anna “CyberTailor”