[issue40501] Deprecate and remove ctypes usage in uuid

[Steve Dower]

Steve Dower  added the comment:


New changeset d6b727e2c947240804b8e434b305ba2890122550 by Steve Dower in branch 
'master':
bpo-40501: Replace ctypes code in uuid with native module (GH-19948)
https://github.com/python/cpython/commit/d6b727e2c947240804b8e434b305ba2890122550


--

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[Steve Dower]

Steve Dower  added the comment:

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?

--

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[Ned Deily]

Ned Deily  added the comment:

> (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.

--
nosy: +ned.deily

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +19263
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/19948

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[STINNER Victor]

STINNER Victor  added the comment:

> 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.

--

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[Steve Dower]

Steve Dower  added the comment:

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.

--

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[STINNER Victor]

STINNER Victor  added the comment:

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.

--
nosy: +vstinner

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[Steve Dower]

Steve Dower  added the comment:

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!

--

___
Python tracker 

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

[issue40501] Deprecate and remove ctypes usage in uuid

[Steve Dower]

New submission from Steve Dower :

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.

--
components: Library (Lib)
messages: 368066
nosy: steve.dower
priority: normal
severity: normal
stage: test needed
status: open
title: Deprecate and remove ctypes usage in uuid
versions: Python 3.9

___
Python tracker 

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