Boost C++ Libraries: Ticket #7248: UUID Conditional jump or move depends on uninitialised value(s)

Andy Tompkins — Wed, 12 Sep 2012 02:19:34 GMT

I believe I have fixed this with trunk commit #80501.

Can you confirm please.

status changed; resolution set

Andy Tompkins — Fri, 14 Jun 2013 19:12:32 GMT

status new → closed
resolution → fixed

status, version, severity changed; resolution deleted

k.stuhlemmer@… — Tue, 22 Jul 2014 06:56:52 GMT

status closed → reopened
version Boost 1.48.0 → Boost Development Trunk
resolution fixed
severity Optimization → Showstopper

This is a serious issue! Using uninitialized variables (i.e. _rd[]) as extra source of randomness has been proven to be a very bad idea (see http://kqueue.org/blog/2012/06/25/more-randomness-or-less). You should consider to rework the seed generation or remove it completely. Boost is believed to be high-quality code and many developers trust on it. In this certain case its usage is simply dangerous.

anonymous — Sat, 11 Oct 2014 01:23:07 GMT

I have observed the same issue in boost 1.55.0

Are there any plans to fix this?

Besides creating a lot of noise in my case, I agree that relying on uninitialized values as a source of entropy is simply not safe.

douwegelling@… — Tue, 28 Mar 2017 11:14:44 GMT

I'd just like to draw some attention to this issue. I'd prefer if uuid::random_generator did not provide a default constructor to the current state where a you can do so, but it takes data from uninitialized variables in lieu of entropy.

James E. King, III — Sat, 12 Aug 2017 23:32:35 GMT

I'm wondering if we should simply eliminate the current default construction with the sha1 code, and require a random generator from boost::random, such as mt19937 (or perhaps that becomes the default), or random_device.

status, version, severity, milestone changed; resolution set

James E. King, III — Sun, 27 Aug 2017 18:30:49 GMT

status reopened → closed
version Boost Development Trunk → Boost 1.55.0
resolution → worksforme
severity Showstopper → Problem
milestone To Be Determined → Boost 1.66.0

This is no longer reproducible. I believe the issue was fixed in boost 1.59 or earlier; see https://svn.boost.org/trac10/ticket/9407. I am resolving this as "worksforme" in boost 1.66 however I suspect it was fixed as far back as 1.59.