I'm classifying this as a security issue, since using uuid_generate_time() -- i.e. the not _safe() variety -- does return collisions in real world cases that we've seen, and those could have security implications. However, I don't know that this can be exploited in any real world cases, so I'm not making it private or sending tosecurity@.The basic problem is that uuid.uuid1() uses uuid_generate_time(3), but if the synchronization methods used in that C function's manpage are not used, then two concurrent processes can -- and do in our cases -- return the same UUID.I would propose that if uuid_generate_time_safe() is available, this should be used instead, and the return value should be checked to see if a safe method was used.  If not, then uuid1() should fall back to the pure-Python approach.

FWIW, I'm not convinced the pure python fallback code is sufficient either; time.time() doesn't have the necessary resolution AFAIK? Also clock_seq is generated using the random module's messerne twister, not SystemRandom().

On Nov 06, 2014, at 08:10 PM, Alex Gaynor wrote:>FWIW, I'm not convinced the pure python fallback code is sufficient either;>time.time() doesn't have the necessary resolution AFAIK? Also clock_seq is>generated using the random module's messerne twister, not SystemRandom().Perhaps, but that's a different bug. ;)-----snip snip-----from uuid import UUIDimport ctypesimport ctypes.utillib = ctypes.CDLL(ctypes.util.find_library('uuid'))_ugts = lib.uuid_generate_time_safe_buffer = ctypes.create_string_buffer(16)retval = _ugts(_buffer)# Remember, this is C!is_safe = (retval == 0)print('{} is safe? {}'.format(UUID(bytes=_buffer.raw), is_safe))-----snip snip-----On Ubuntu 14.10, gives me:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx is safe? True

I changed my mind on whether this should affect older versions of Python.  I have a branch which adds an UUID.is_safe attribute that relays the platform information about whether the UUID was generated safely or not, if available.  It's an enum named SafeUUID with values .safe, .unsafe, .unknown (the default).

New changeset8c130d7f8114158f5b94749032ec0c17dba96f83 by GitHub in branch 'master':bpo-22807: Expose platform UUID generation safety information. (#138)https://github.com/python/cpython/commit/8c130d7f8114158f5b94749032ec0c17dba96f83

I don't understand well this change.What am I supposed to do with an UUID with safe=False? Should I loop on the function until I get safe==True?"safe for multiprocessing applications"Does it mean unique on the whole system?I looked at uuid_generate_time_safe(3) manual page which mention "synchronization mechanisms (see above)" but they are not documented.http://manpages.ubuntu.com/manpages/zesty/en/man3/uuid_generate.3.html> I'm classifying this as a security issue, (...)This issue was only fixed in Python 3.7. Does it mean that it's no more considered as as security vulnerability?

On Feb 20, 2017, at 02:21 PM, STINNER Victor wrote:>What am I supposed to do with an UUID with safe=False? Should I loop on the>function until I get safe==True?It would be an application dependent response.  It might be that you wouldcheck some other attributes of your platform (e.g. are the OS packages thatshould be installed to give you safe UUIDs?).  Or your application may notcare that much, or your application may refuse to continue to run on platformswithout safe UUIDs, or you might use some application-level synchronizationmethods to guarantee safe UUIDs (e.g. store the unsafe or unknown ones in adatabase and check that new ones are not already used).The point of this change is that it provides information to the applicationcreating UUIDs that wasn't previously available.>"safe for multiprocessing applications">>Does it mean unique on the whole system?>>I looked at uuid_generate_time_safe(3) manual page which mention>"synchronization mechanisms (see above)" but they are not documented.>http://manpages.ubuntu.com/manpages/zesty/en/man3/uuid_generate.3.htmlI believe some systems at least use interprocess communication with a daemonto provide the synchronization.  Yes, it would be system-wide.>> I'm classifying this as a security issue, (...)  >>This issue was only fixed in Python 3.7. Does it mean that it's no more>considered as as security vulnerability?I should remove that tag.  While this could have an impact on applicationsecurity, it's not a security issue *in Python* itself.

Oh, and because the fix is an API change, I don't believe it should be applied to earlier versions.  So I think adding the API in 3.7 is all the fix needed here.

>>> import uuid>>> u=uuid.uuid4()>>> u.is_safe<SafeUUID.unknown: None>Can't we consider that UUID4 is always safe?

On Feb 20, 2017, at 03:45 PM, STINNER Victor wrote:>Can't we consider that UUID4 is always safe?It's not a guarantee made by the underlying platform, so I chose to use thedefault SafeUUID.unknown value there.

This breaks pickle compatibility. UUIDs pickled in 3.7 can't be unpickled in older Python versions because they do not have the SafeUUID class. Seeissue30977 for possible solution.

The fix forissue30977 did fix the unpickling in older versions. It was only applied to the master (i.e. 3.8) branch, though.I've createdissue34621 to deal with this separately.