On Tue, Nov 16, 2021 at 5:04 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2021-11-16 at 23:20:45, rsbecker@xxxxxxxxxxxxx wrote: > > 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
