[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Ronald Oussoren]

Ronald Oussoren  added the comment:

@terrygreeniaus: Are you running macOS 11 on your MacBook Pro?

If so, could you verify the hardware address of the iBridge interface? 

I've checked to libc sources on opensource.apple.com and those don't seem to 
contain code to treat the iBridge interface specially. 

I've also attached a small program that dumps the Mac addresses of interfaces 
using the same mechanism as used by the UUID code in libc. If the Mac address 
is unchanged they may have done something that affects that code.

--
Added file: https://bugs.python.org/file49794/dumpaddr.c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I got feedback on FB889: Apple says they have fixed the issue (they don't 
mention in what version, but I expect 11.2). I haven't checked this yet.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Ronald Oussoren]

Ronald Oussoren  added the comment:

the most recent UUID implementation on opensource.apple.com: 
https://opensource.apple.com/source/Libc/Libc-1353.100.2/uuid/uuidsrc/gen_uuid.c.auto.html

The implementation of get_node_id() doesn't ignore the iBridge interface, which 
means uuid_generate_time(3) could run into this issue (and because of that, 
Python's uuid module)

I've filed an issue with Apple about this: FB889

Note that switching to libuuid from util-linux wouldn't help here, that also 
doesn't ignore the iBridge interface.

I'm tempted to close this issue as "3th-party" because this is bug in the 
system implementation of uuid_generate_time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Ronald Oussoren]

Ronald Oussoren  added the comment:

An option is to use the host UUID instead of libuuid (as used by the _uuid 
extension). This has two problems though: (1) the RFC prescribes that the node 
id is a IEEE 802 MAC address, and (2) the host UUID is a full UUID and would 
have to be post processed.   Because of this I don't think this is a usable 
alternative.

The relevant API is gethostuuid().

Related stackoverflow: 
https://stackoverflow.com/questions/933460/unique-hardware-id-in-mac-os-x

Related elastic issue (where I found gethostuuid): 
https://github.com/elastic/beats/issues/14439

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I've verified that python 3.8 and 3.9 use the system uuid functions (part of 
libsystem). This means this issue might not be fixable without dropping the use 
of the _uuid extension.

@terrygreeniaus: Can you still reproduce this issue?  If so, does "import 
_uuid" work on your system?


I do have a system with an iBridge interface, but that interface is below the 
active network interface and is never used.   That system is headless, I cannot 
easily try to reproduce the issue by messing with its network interfaces.

I wonder how useful it is to try to fix this issue, I'd personally prefer to 
use uuid4() because that doesn't leak information about the host.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Vedran Čačić]

Vedran Čačić  added the comment:

Yes, you're right. Xoring can be replaced by any key-derivation function, 
though of course that's probably overkill.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Jeffrey Kintscher]

Change by Jeffrey Kintscher :


--
nosy: +Jeffrey.Kintscher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Terry Greeniaus]

Terry Greeniaus  added the comment:

xoring does not guarantee uniqueness and has a good chance of discarding it, so 
it seems like a bad idea to me.

Suppose I have exactly two adapters with MAC addresses 0 and 3.
Suppose you have exactly two adapters with MAC addresses 1 and 2.

We'll both xor all our addresses and both get 0 ^ 3 == 1 ^ 2.  This trivially 
extends to 48 bits.

Suppose I have exactly two adapters from the same manufacturer.  The xor will 
throw away all of the "uniqueness" guaranteed by the manufacturer OUI and 
replace it with 0.

Suppose you have exactly two adapters from a different manufacturer (and 
nothing else).  The xor will throw away all of your "uniqueness" guaranteed by 
the manufacturer OUI and replace it with 0.

Now the only uniqueness between your UUIDs and my UUIDs will be the timestamp 
and the low-order bits of the xor'd MAC, whereas without the xor your UUIDs and 
my UUIDs would have absolutely been guaranteed to be unique since they are from 
different manufacturers with different OUIs.

I realize that the documentation for uuid1() states that it isn't guaranteed to 
give unique addresses if the time synchronization necessary isn't supported by 
the platform, so I suppose this could even be a documentation fix if no real 
solution can be found, but that would be really undesirable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Vedran Čačić]

Vedran Čačić  added the comment:

+1 on xoring all MAC addresses to get NodeID. Since it is only done once at 
import time, it shouldn't be too expensive (many other things including OS 
calls are done at initialization). But yes, if the problem goes away with new 
version of _uuid, then the fix isn't needed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Note that recent commits to the trunk and 3.8 and 3.9 branches have added a 
_uuid module using libuuid (and the comparable Windows API). I'd expect that 
this extension will also be used on macOS.

I'd advise to check if this issue is still present when using that extension 
before spending too much time on a fix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

> The question then is: is there any way for the uuid module to recognize and 
> ignore such interfaces other than by the hardcoded MAC address?

Could uuid1 xor all mac addresses on MacOS? The result would be deterministic 
and unique as long as there is at least one mac address that is unique.

--
nosy: +remi.lapeyre

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Vedran Čačić]

Vedran Čačić  added the comment:

I'd like to point out that _even_ if you do reuse MAC address:

1. node IDs don't have to be derived from MAC addresses only (though in 
practice they usually are - I'm just saying the RFC gives you permission to 
include other information in it).

2. The time resolution is 100ns. As long as your UUID generations are more than 
0.2μs apart, you're safe from collisions.

3. There is still a clock sequence, which for these purposes can be viewed as 
random. Even if you _do_ generate UUIDs on different machines with same MAC and 
naive nodeID-deriving algorithm, two or more of them within the same 
100ns-interval, there is still only a probability of 1/16384 (62ppm) of 
collision.

In short, it's probably not a problem, though if there is an easy fix, of 
course it should be applied. Currently, there are two ways to indicate "this is 
not a real unique MAC address" that UUID recognizes: 

# Virtual interfaces, such as those provided by
# VPNs, do not have a colon-delimited MAC address
# as expected, but a 16-byte HWAddr separated by
# dashes. These should be ignored in favor of a
# real MAC address

and the 41st bit test /More details at #32107/. Maybe there is a third way, but 
if the above address doesn't play by these rules, maybe hardcoding it isn't so 
bad an idea.

--
nosy: +veky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41552] uuid.uuid1() on certain Macs does not generate unique IDs

[Ned Deily]

Ned Deily  added the comment:

FWIW, I see similar behavior on a 2017 MBP running with 10.15.6 or 11.0 (Big 
Sur) beta 4. That's ... odd that there is a non-unique MAC address. (Not 
surprisingly, there is no such problem on an iMac that doesn't have the 
touchbar subsystem.) That particular interface doesn't show up in the 
user-visible Network panel of System Preferences so it can't even be easily 
reordered there.  I suppose there is a good reason why it appears at the top of 
the interface list but, yes, we don't want to be using a non-unique MAC address 
to generate UUIDs. The question then is: is there any way for the uuid module 
to recognize and ignore such interfaces other than by the hardcoded MAC address?

--
stage:  -> needs patch
title: uuid.uuid1() on macOS doesn't generate unique IDs -> uuid.uuid1() on 
certain Macs does not generate unique IDs
versions: +Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com