On Tue, Nov 16, 2021 at 5:04 PM brian m. carlson
[off-list ref] wrote:

On 2021-11-16 at 23:20:45, rsbecker@nexbridge.com wrote:

quoted

We do link with libcurl and use OpenSSL as a DLL to handle TLS. The
underlying random source for the nonstop-* configurations as of
OpenSSL 3.0 are PNRG supplied by the vendor (HPE) on ia64 and the
hardware rdrand* instructions on x86. I know that part of the OpenSSL
code rather intimately.

Great, as long as you don't define NO_OPENSSL, I think I can make this
work with OpenSSL by calling RAND_bytes, which will use whatever OpenSSL
uses.

not that RAND_bytes return high entropy bytes (like /dev/random) and
is therefore limited and prone to draining, blocking and erroring when
drained, so if we are going this route, will most likely need a second
layer on top that doesn't block (like arc4random does), and at that
point I would think we would rather use something battle tested than
our own.

for the little amount of random data we need, it might be wiser to
fallback to something POSIX like lrand48 which is most likely to be
available, but of course your tests that consume lots of random data
will need to change.

Carlo

PS. Probably missing context as I don't know what was discussed
previously, but indeed making this the libc problem by using mkstemp
(plus some compatibility on top), like Peff mentioned seems like a
more straightforward "fix"



  I'll work on that for a v2 to see if that will meet the needs for

your platform, and if not, I'll try something else.

That should also have the pleasant side effect of making this more
portable even for those people who do have less common platforms, since
OpenSSL will likely be an option there.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA