Skip to content

libpython should not be linked with libcrypt #89596

Closed

Description

@floppym
mannequin
BPO 45433
Nosy @vstinner, @floppym, @thesamesam
PRs
  • bpo-45433: Do not link libpython against libcrypt #28881
  • 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 = <Date 2021-10-11.23:24:50.373>
    created_at = <Date 2021-10-11.18:11:14.569>
    labels = ['build', '3.11']
    title = 'libpython should not be linked with libcrypt'
    updated_at = <Date 2021-10-12.02:58:00.239>
    user = 'https://github.com/floppym'

    bugs.python.org fields:

    activity = <Date 2021-10-12.02:58:00.239>
    actor = 'thesamesam'
    assignee = 'none'
    closed = True
    closed_date = <Date 2021-10-11.23:24:50.373>
    closer = 'vstinner'
    components = ['Build']
    creation = <Date 2021-10-11.18:11:14.569>
    creator = 'floppymaster'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 45433
    keywords = ['patch']
    message_count = 3.0
    messages = ['403663', '403701', '403702']
    nosy_count = 3.0
    nosy_names = ['vstinner', 'floppymaster', 'thesamesam']
    pr_nums = ['28881']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'compile error'
    url = 'https://bugs.python.org/issue45433'
    versions = ['Python 3.11']

    Activity

    1. floppym commented on Oct 11, 2021

      floppymmannequin
      MannequinAuthor

      In https://bugs.python.org/issue44751, crypt.h was removed from Python.h. This would imply that libpython is not meant to expose any crypt-related symbols.

      In fact, it looks like libpython does not use crypt() or crypt_r() at all. These are only used by cryptmodule.

      In configure.ac, we have this this logic to determine if crypt_r() is available:

      # We search for both crypt and crypt_r as one or the other may be defined
      # This gets us our -lcrypt in LIBS when required on the target platform.
      AC_SEARCH_LIBS(crypt, crypt)
      AC_SEARCH_LIBS(crypt_r, crypt)
      
      AC_CHECK_FUNC(crypt_r,
        AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
      #define _GNU_SOURCE  /* Required for crypt_r()'s prototype in glibc. */
      #include <crypt.h>
      ]], [[
      struct crypt_data d;
      char *r = crypt_r("", "", &d);
      ]])],
          [AC_DEFINE(HAVE_CRYPT_R, 1, [Define if you have the crypt_r() function.])],
          [])
      )
      

      The AC_SEARCH_LIBS macro adds "-lcrypt" to LIBS, and this gets passed down to the link command for libpython. This is probably not intentional.

      The HAVE_CRYPT_R value is used in _cryptmodule.c. setup.py performs its own check for libcrypt when building the module.

      I think the value of LIBS should be saved before the AC_SEARCH_LIBS calls and restored after the AC_CHECK_FUNC call. I have tested this locally on Gentoo Linux, and it seems to work fine.

      I will work on a pull request.

    2. 7 remaining items

    3. transferred this issue fromon Apr 10, 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.11only security fixesbuildThe build process and cross-build

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions