On 2014-08-12 at 08:07 -0700, Todd Lyons wrote:
> OpenBSD 5.5 was released on May 1 2014. In it, there appears to be
> movement on deprecating arc4random_* function calls. A build client
> builds all of the object files correctly, but is failing to link the
> final exim binary with the following error:
Already covered in:
https://github.com/Exim/exim/issues/14
The removed functions were no longer needed on OpenBSD but are still
needed elsewhere; removing the function call would introduce repeating
random numbers by not protecting against a fork except on newer OS
releases which automatically handle that.
As I closed that bug: OpenBSD made a backwards incompatible API break
because the function is no longer needed for _them_, ignoring that
conforming to that API would introduce potential security holes on other
platforms, which is a distinctly anti-social move to make.
Okay, this is our "vaguely random" API which is "reasonable efforts",
not for crypto keys, but the users of it are doing things like
generating semi-secrets for email headers token auth -- that was the
use-case which led to my adding ${randint:...} to Exim in the first
place, to at least be able to introduce something roughly sane on
platforms with enough support for it, and only degrade to crappy entropy
on platforms which are effectively unmaintained. It should not degrade
across an Exim release, only by moving to an old OS. The problem
scenario is someone using randint in the master process and then in
receiver processes too; we don't know how common that is, and the code
was written to support it, from the beginning, by handling forks. The
parent hangs around, so pid reuse is not a problem.
If we now have an OpenBSD build bot and want to support it, first class,
then we need a new #define to guard on, "HAVENOT_ARC4RANDOM_STIR"
perhaps, then define that in "OS/os.h-OpenBSD". A comment on the guard
should make clear that before defining this for a new OS, we need to
make sure that all known releases of that OS support auto-mixing,
because if not then defining the guard is weakening protection.
This should not be defined by default for FreeBSD. The box I wrote the
code on (and writing this email reply on) requires the explicit stir;
I'm working to retire the box but this is just an example of the
problems caused when nitwits break APIs by removing features needed for
security elsewhere, with an "I'm all right, who cares about them"
attitude. (Which I believe affects older releases of their own OS,
although I haven't double-checked that).
-Phil
