libpython should not be linked with libcrypt

[floppym]

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']

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

I will work on a pull request.

[vstinner]

New changeset be21706 by Mike Gilbert in branch 'main':
bpo-45433: Do not link libpython against libcrypt (GH-28881)
be21706

[vstinner]

Nicely spotted, thanks for the fix!

I prefer to not backport to avoid any risk of regression. In my experience, the build system is fragile.