The uuid module uses ctypes to try and load likely system libraries to provide some functionality of the uuid module.

This is a security risk (depending on your sensitivity to DLL hijacking), but it also seems to be not very necessary? It would be nice to remove the ctypes usage from an otherwise (almost) pure Python module.

There are three scenarios where ctypes is used in this module:

• get libuuid.uuid_generate_time_safe and uuid_generate_time (if _uuid was not compiled)
• get rpcrt4.UuidCreateSequential (on Windows, depending on how the libuuid lookup failed)
• GetSystemDirectory (on Windows, safe to replace with alternative approach)

I'll happily move the UuidCreateSequential call into _uuid and add it to the Windows build, but it's not clear whether the libuuid lookup is important or not. If anyone knows of scenarios where you can't compile against libuuid but can load it with ctypes, would be great to hear about it!

uuid.py has a long history. The recent history is the addition of the _uuid module which exposes libuuid function properly. IMHO it's a better approach than ctypes.

On Windows, it seems like ctypes remains used to get access to Windows function UuidCreateSequential(). It is used by uuid.getnode() for example. We should expose UuidCreateSequential() in _uuid rather than using ctypes for that.

I propose to do that in two steps:

(A) Ensure that _uuid works on macOS, FreeBSD and Linux, especially in the macOS installer of python.org. If yes, remove the ctypes code to access libuuid functions.

(B) Add a function to _uuid to expose Windows UuidCreateSequential(), use it in uuid.py and remove the related ctypes code.

Both steps can be done in parallel.

Do you think either need a deprecation cycle? I'd say not for the Windows change, but I'm not sure whether people could be relying on libuuid showing up after build.

Do you think either need a deprecation cycle? I'd say not for the Windows change, but I'm not sure whether people could be relying on libuuid showing up after build.

If the behavior doesn't change, no deprecation is needed.

For example, if libuuid was already used trough _uuid module, the ctypes code path is basically just dead code. But it should be checked manually.

(A) Ensure that _uuid works on macOS, FreeBSD and Linux, especially in the macOS installer of python.org.

FWIW, a spot check shows that _uuid builds and test_uuid passes both sets of its tests, e.g. TestUUIDWithExtModule and TestUUIDWithoutExtModule, with current python.org macOS installers on macOS releases of interest. So, AFAICT, we have no need for the ctypes fallback on at least macOS 10.6 or later and we don't actively support anything older than that.

Thanks Ned.

There are some platform.version() checks in there that I'm basically ignoring right now - are those unnecessary? Shall I clean them up too?

New changeset d6b727e by Steve Dower in branch 'master':
bpo-40501: Replace ctypes code in uuid with native module (GH-19948)
d6b727e

This is fixed, right?

$ grep ctypes Lib/uuid.py 
# not result

Right, I close the issue.