Skip to content

Deprecate and remove ctypes usage in uuid #84681

Closed
Closed
Deprecate and remove ctypes usage in uuid#84681
Labels
3.9 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directory

Description

@zooba
zooba
opened on May 4, 2020
BPO 40501
Nosy @vstinner, @ned-deily, @zooba, @corona10
PRs
  • bpo-40501: Replace ctypes code in uuid with native module #19948
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = None
created_at = <Date 2020-05-04.16:34:02.882>
labels = ['library', '3.9']
title = 'Deprecate and remove ctypes usage in uuid'
updated_at = <Date 2020-05-12.22:32:49.137>
user = 'https://github.com/zooba'

    bugs.python.org fields:

    activity = <Date 2020-05-12.22:32:49.137>
actor = 'steve.dower'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-05-04.16:34:02.882>
creator = 'steve.dower'
dependencies = []
files = []
hgrepos = []
issue_num = 40501
keywords = ['patch']
message_count = 8.0
messages = ['368066', '368067', '368068', '368070', '368071', '368220', '368296', '368746']
nosy_count = 4.0
nosy_names = ['vstinner', 'ned.deily', 'steve.dower', 'corona10']
pr_nums = ['19948']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue40501'
versions = ['Python 3.9']

    Activity

    1. zooba commented on May 4, 2020

      @zooba
      zooba
      on May 4, 2020
      MemberAuthor

      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.

    2. zooba
      added
      3.9 (EOL)end of life
      stdlibStandard Library Python modules in the Lib/ directory
      on May 4, 2020

    3. zooba commented on May 4, 2020

      @zooba
      zooba
      on May 4, 2020
      MemberAuthor

      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!

    4. vstinner commented on May 4, 2020

      @vstinner
      vstinner
      on May 4, 2020
      Member

      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.

    5. zooba commented on May 4, 2020

      @zooba
      zooba
      on May 4, 2020
      MemberAuthor

      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.

    6. vstinner commented on May 4, 2020

      @vstinner
      vstinner
      on May 4, 2020
      Member

      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.

    7. ned-deily commented on May 6, 2020

      @ned-deily
      ned-deily
      on May 6, 2020
      Member

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

    8. zooba commented on May 6, 2020

      @zooba
      zooba
      on May 6, 2020
      MemberAuthor

      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?

    9. zooba commented on May 12, 2020

      @zooba
      zooba
      on May 12, 2020
      MemberAuthor

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

    10. ezio-melotti
      transferred this issue fromon Apr 10, 2022

    11. iritkatriel commented on May 18, 2022

      @iritkatriel
      iritkatriel
      on May 18, 2022
      Member

      This is fixed, right?

    12. vstinner commented on May 18, 2022

      @vstinner
      vstinner
      on May 18, 2022
      Member
      $ grep ctypes Lib/uuid.py 
# not result

      Right, I close the issue.

    13. vstinner
      closed this as completedon May 18, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.9 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directory

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions