Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to  guarantee the timeliness or suitability of a resolution.

    If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution. 

    For information on how to contact the Red Hat production support team, please visit:

    https://www.redhat.com/support/process/production/#howto

We don't update packages in rhel just because there is newer version. Package updates cause disruptions, so there must be some good reason, why we should update that package.

What exactly does not work in version we currently ship? (Reproducer is needed.)

The patch is relatively minor, but brings "uuid" into line with expected behavior RFC-4122.

Specifically, v1 uuid's generated on the same host are expected to have the same 'node' field (the MAC address derived field), as per Section 4.1.6:

4.1.6.  Node

   For UUID version 1, the node field consists of an IEEE 802 MAC
   address, usually the host address.  For systems with multiple IEEE
   802 addresses, any available one can be used.  The lowest addressed
   octet (octet number 10) contains the global/local bit and the
   unicast/multicast bit, and is the first octet of the address
   transmitted on an 802.3 LAN.

and 4.2.2:

4.2.2.  Generation Details

   Version 1 UUIDs are generated according to the following algorithm:

   o  Determine the values for the UTC-based timestamp and clock
      sequence to be used in the UUID, as described in Section 4.2.1.

[...]

   o  Set the node field to the 48-bit IEEE address in the same order of
      significance as the address.

here we see that the node field in uuid-1.6.1-10 for v1 uuid's does not correspond to any MAC address associated with the host:


[philipp@gwtest uuid]$ uuid -v1
3e233b36-8bfe-11e2-a926-6f81da635566

and indeed tracing the process indicates why (even though it is correctly detecting eth0's MAC address via SIOCGIFHWADDR ioctl, it ignores the  return value and reads 6 bytes from /dev/urandom instead). This is due to a bug where the MAC addresses with the high-bit set are incorrectly inferred to be invalid (the appropriate behavior is to check all 48 bits, not just the high bit of the first octet).


[philipp@gwtest uuid]$ strace uuid -v1
execve("/usr/bin/uuid", ["uuid", "-v1"], [/* 31 vars */]) = 0
brk(0)                                  = 0x2472000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fafbe1fa000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=64580, ...}) = 0
mmap(NULL, 64580, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fafbe1ea000
close(3)                                = 0
open("/usr/lib64/libossp-uuid.so.16", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20$\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=48560, ...}) = 0
mmap(NULL, 2143728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fafbddd0000
mprotect(0x7fafbdddb000, 2097152, PROT_NONE) = 0
mmap(0x7fafbdfdb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7fafbdfdb000
close(3)                                = 0
open("/lib64/libnsl.so.1", O_RDONLY)    = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p@\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=113432, ...}) = 0
mmap(NULL, 2198192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fafbdbb7000
mprotect(0x7fafbdbcd000, 2093056, PROT_NONE) = 0
mmap(0x7fafbddcc000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7fafbddcc000
mmap(0x7fafbddce000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fafbddce000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY)      = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\355\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1916528, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fafbe1e9000
mmap(NULL, 3745960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fafbd824000
mprotect(0x7fafbd9ad000, 2097152, PROT_NONE) = 0
mmap(0x7fafbdbad000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x189000) = 0x7fafbdbad000
mmap(0x7fafbdbb2000, 18600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fafbdbb2000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fafbe1e8000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fafbe1e7000
arch_prctl(ARCH_SET_FS, 0x7fafbe1e8700) = 0
mprotect(0x7fafbdbad000, 16384, PROT_READ) = 0
mprotect(0x7fafbddcc000, 4096, PROT_READ) = 0
mprotect(0x7fafbe1fb000, 4096, PROT_READ) = 0
munmap(0x7fafbe1ea000, 64580)           = 0
brk(0)                                  = 0x2472000
brk(0x2493000)                          = 0x2493000
open("/dev/urandom", O_RDONLY)          = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getpid()                                = 4980
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=d0:27:88:59:38:8b}) = 0
close(4)                                = 0
read(3, "\203O", 2)                     = 2
read(3, "\206\371\224\314G\37", 6)      = 6
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fafbe1f9000
write(1, "4f51a2e4-8bfe-11e2-8f83-87f994cc"..., 374f51a2e4-8bfe-11e2-8f83-87f994cc471f
) = 37
close(3)                                = 0
exit_group(0)                           = ?
[philipp@gwtest uuid]$ 

[philipp@gwtest uuid]$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether d0:27:88:59:38:8b brd ff:ff:ff:ff:ff:ff
5: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
6: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
[philipp@gwtest uuid]$ 


Building and running 1.6.2-16 on the same host:


[philipp@gwtest uuid]$ uuid -v1
d07cc252-8c00-11e2-be5f-d0278859388b
[philipp@gwtest uuid]$ 


And here the last field (the 'node' field) does indeed correspond to eth0's MAC address.

There are applications where the implicit structure of version 1 uuid's is essential, and the repeatability of the 'node' field is used for tracing (since it's always the same for any given originator) or even for signing.

Violating this requirement weakens those applications.

Is there anything else? Because this bug *won't* be fixed with update to 1.6.2.
It's our own patch we use in Fedora and there is already bug report for this issue in RHEL 6 as bug #833429

If you have no other issue with uuid 1.6.1, close this bug as duplicate of 833429.

I'm confused. You reference bug #833429 but that's unresolved as well.

And yes, the patch:

https://bugzilla.redhat.com/attachment.cgi?id=590064

was my fix (and I upstreamed it, and it made its way into 1.6.2). So I don't understand what the impasse is.

We can integrate my patch in #833429 and release that, or we can do a version bump to 1.6.2 and pick up the fix upstream.

Either solution would resolve the issue, but neither bug seems to have advanced so I'm not sure what the blockage is.

Or for that matter, what is additionally needed from me.

Ok, never mind. I understand.

Despite filing a bug and submitting a patch with it, this fix has not yet been integrated upstream and 1.6.2 does not include the fix.

Not clear when 1.6.3 is do out or if this fix will be present since I've had no feedback on the proposed patch.

That referenced bug #833429 is waiting for product management approval. 

To sum it up, is 833429 fix enough for you or do you have any other reason why uuid rebase is required?

(In reply to Michal Hlavinka from comment #8)
> That referenced bug #833429 is waiting for product management approval. 
> 
> To sum it up, is 833429 fix enough for you or do you have any other reason
> why uuid rebase is required?

No, no rebase necessary.  Just need the MAC portion fixed per the patch.

*** This bug has been marked as a duplicate of bug 833429 ***