apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Bowsher <ma...@ukf.net>
Subject Re: APR-util UUID generator broken
Date Fri, 14 Apr 2006 10:14:10 GMT
Hash: SHA1

Ralf S. Engelschall wrote:
> As UUIDs found in Subversion repositories looked strange to me...
> | $ svnadmin create /tmp/repository
> | $ uuid -d `cat /tmp/repository/db/uuid`
> | UUID:    4ac08136-9f10-0410-b9d4-41ac6b128626
> | variant: DCE 1.1, ISO/IEC 11578:1996
> | version: 0 (unknown)
> | content: 4A:C0:81:36:9F:10:04:10:39:D4:41:AC:6B:12:86:26
> |          (not decipherable: unknown UUID version)
> ...I've reviewed the UUID generator in APR-util. It unfortunately is
> totally broken and generates neither valid (format) nor useful (content)
> RFC4122 UUIDs.

REMOVING CC to dev@subversion, as this is entirely an APR issue.

> It has the following particular problems:
> 1. ERROR: for generating the version 1 UUIDs the function apr_time_now()
>    (using Unix Epoch time basis) is used although a local function
>    get_system_time() was defined (which time adjusts to the UUID time
>    basis). This way the time in the generated UUIDs is time shifted and
>    this way incorrect.
> 2. ERROR: UUIDs have a 128 bit binary representation where each field is
>    encoded in _network byte order_. As a result the UUIDs generated
>    by APR-util were totally bogus as even the "version" field was
>    encoded into the wrong part of the 128 bit. Additionally, as another
>    side-effect, the encoded time was also totally bogus, of course.

Thankyou for taking the time to hunt down bugs, but you could have saved
yourself a lot of time by just checking trunk. Both of the above are
already fixed.

I did not propose a backport at the time I fixed the bugs, but I take it
from your considerable action on this topic that you would like one. I
guess that's fine - the change does not have compatibility issues that I
am aware of.

> 3. OPTIMIZATION: for generating random content the local
>    get_system_time() function (which is based on apr_time_now()) is used
>    which time-adjusts for the UUID vs Unix Epoch time. For generating
>    random bytes it is fully sufficient to just use plain apr_time_now().

> Index: apr-util-1.2.6/crypto/getuuid.c
> --- apr-util-1.2.6/crypto/getuuid.c.orig	2005-02-04 21:45:35 +0100
> +++ apr-util-1.2.6/crypto/getuuid.c	2006-04-04 19:49:37 +0200
> @@ -131,7 +131,7 @@
>      /* crap. this isn't crypto quality, but it will be Good Enough */
> -    get_system_time(&time_now);
> +    time_now = apr_time_now();
>      srand((unsigned int)(((time_now >> 32) ^ time_now) & 0xffffffff));
>      return rand() & 0x0FFFF;

This seems sensible to me.

Could someone give a second opinion that this is fine, and isn't going
to impact the randomness quality?


Version: GnuPG v1.4.2.1 (Cygwin)


View raw message