Subject: Re: [boost] Boost.Uuid and header-only support
From: James E. King, III (jking_at_[hidden])
Date: 2017-11-04 17:37:47
On Sat, Nov 4, 2017 at 11:40 AM, Peter Dimov via Boost <
> Andrey Semashev wrote:
> The proposal to make Boost.Random header-only was rejected by Steven.
> This sounds like essential context that might have been worth mentioning.
I specifically did not mention the PR resolution because my intention was
to find a path forward, not to bring attention to that decision.
Steven is right that we're still dependent on Boost.System, this needs to
> be solved somehow.
> To get back to Uuid. The whole seed_rng file needs to be retired. It's
> only an implementation detail of a primitive operation that returns N
> random bytes. At the time seed_rng was written, there was no good way of
> obtaining high quality randomness from the OS, but this is not the case
boost::uuids::detail::seed_rng has the following problems:
1. It duplicates the behavior of boost::random_device.
2. It is unnecessarily complex (does way more than boost::random_device).
3. It ignores errors, leading potentially to not properly seeding the RNG.
4. It has no support for Universal Windows Platform.
> What the Uuid library needs, when generating a random UUID, is just an
> array of random bytes; there's no need to create a random number generator,
> then seed it. None at all. This is historical baggage.
> And in my opinion, all the conceptification and templatization in James's
> PR is completely unnecessary and just adds complexity. What we need is this:
> int get_random_bytes( void * buffer, size_t size ); // returns errno
> This happens to match the Linux function with the same name but this is
> The implementation of this function needs to
> - read from /dev/urandom on POSIX
> - use RtlGenRandom on Windows desktop
> - use Bcrypt on Windows non-desktop
It would be safer to use Wincrypt on windows desktop for these reasons:
1. RtlGenRandom has no published interface and may disappear at any time.
2. Consumers who use their own Wincrypt provider for entropy would be
broken by such a change.
> We have to decide where to put it though. Utility springs to mind as a
> first candidate.
Something called "get_random_bytes" seems like it would belong in
> Switching topics back to Boost.Random, I consider the use of the token to
> select a cryptographic provider a bad practice. Even the POSIX path should
> ignore the token. get_random_bytes is the way to go. But that's a separate
The token allows the POSIX implementation to use a different entropy
provider device (other than /dev/urandom) or even a text file.
There may be reasons why folks use their own, for example in the government
sector, so any change in that area would be a breaking change.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk