std: add CCRandomGenerateBytes macOs native api.

[devnexen]

No description provided.

[devnexen]

cc @kubkon

I think it can replace, for iOs/macOs only tough, the actual arc4random_buf call from the getrandom wrapper for similar reasons as openssl did (e.g. this call returning a status, possible issue with no len with arc4random_buf, ...), what do you think ?

[kubkon]

cc @kubkon

I think it can replace, for iOs/macOs only tough, the actual arc4random_buf call from the getrandom wrapper for similar reasons as openssl did (e.g. this call returning a status, possible issue with no len with arc4random_buf, ...), what do you think ?

If this is what openssl did I think it's a good idea. @jedisct1 thoughts?

[jedisct1]

As far as I know the underlying RNG is exactly the same. The only difference being that using that API increases the chances of getting an app accepted on the App Store.

Still not a bad thing.

[kubkon]

Mhm, I see. Is there a minimum OS version where this is available? If this is a fairly recent addition we need to either version-gate, or wait a couple of macOS releases for it to be supported across the latest OS versions.

[devnexen]

Since Yosemite/iOs 8.

[kubkon]

Just to double check, CCRandomGenerateBytes is part of libSystem and not of Security.framework?

[devnexen]

not part of Security.framework.

[kubkon]

In that case I would be in favour of moving from arc4random_buf to CCRandomGenerateBytes. Also, as per https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?TD=0510 it's apparently faster and as per microsoft/mimalloc#390 it doesn't silently fail unlike the old interface.

[devnexen]

@kubkon what do you think now ? 🙂

[kubkon]

Are the macOS CI failures related?

[devnexen]

does not seem to be the case, beside it happens only on x86 64 arch.

[devnexen]

seems all pass @kubkon 🙂

[devnexen]

cc @Vexu 🙂