You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
libpython should not be linked with libcrypt #89596
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=Noneclosed_at=<Date2021-10-11.23:24:50.373>created_at=<Date2021-10-11.18:11:14.569>labels= ['build', '3.11']
title='libpython should not be linked with libcrypt'updated_at=<Date2021-10-12.02:58:00.239>user='https://github.com/floppym'
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.
Activity
floppym commentedon Oct 11, 2021
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:
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.
7 remaining items
python3: libcrypt doesn't need to be a dependency of libpython (#28887)