closes bpo-44751: Move crypt.h include from public header to _cryptmodule

[geofft]

https://bugs.python.org/issue44751

Automerge-Triggered-By: GH:benjaminp

[benjaminp]

Do we need to #define _GNU_SOURCE here?

[geofft]

I think no because it's defined by pyconfig.h which is included by Python.h. I'm going to try a build on my Linux box to confirm.

[geofft]

I compiled Python 3.7 on my Debian 9 box with this patch (because that was easiest), and crypt.crypt() works without segfaulting and links crypt_r and there are no warnings in the build log. From inspection, pyconfig.h does define _GNU_SOURCE and does get pulled in by Python.h.

[benjaminp]

Okay, great.

[miss-islington]

@geofft: Status check is done, and it's a success ❌ .

[miss-islington]

@geofft: Status check is done, and it's a success ✅ .

[miss-islington]

Sorry, I can't merge this PR. Reason: 3 of 5 required status checks have not succeeded: 2 expected..

[miss-islington]

@geofft: Status check is done, and it's a success ✅ .

[vstinner]

Thank you! I'm not sure why <crypt.h> was in Python.h initially. Likely because it was easier to put it here.

[Arfrever]

Could you backport this fix to at least 3.9 and 3.10 branches?
This is fix for regression which was previously backported to 2.7 and 3.6 branches.

[miss-islington]

Thanks @geofft for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10.
🐍🍒⛏🤖

[bedevere-bot]

GH-28636 is a backport of this pull request to the 3.10 branch.

[miss-islington]

Thanks @geofft for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

[bedevere-bot]

GH-28638 is a backport of this pull request to the 3.9 branch.

[lazka]

crypt is sadly still needed for packages using python-config:

python3.9-config --libs
 -lcrypt -lpthread -ldl  -lutil -lm -lm

Not sure why python-config leaks all those internals in the first place.

[thesamesam]

crypt is sadly still needed for packages using python-config:

python3.9-config --libs
 -lcrypt -lpthread -ldl  -lutil -lm -lm

Not sure why python-config leaks all those internals in the first place.

I think that was fixed separately in #28881 (but not backported). But agreed, I'm not really sure either, and it leads to a lot of applications linking unnecessarily against extra bits.

This whole thing bit us quite hard downstream when changing to libxcrypt and getting build orders right during the migration, as things were requesting it when they didn't actually need it.

[lazka]

Ah, thanks. I'm going to backport that then.

Yeah, I guess for static builds it makes sense the way it is, but usually that is hidden behind a "--static" flag.

[thesamesam]

Ah, thanks. I'm going to backport that then.

Yeah, I guess for static builds it makes sense the way it is, but usually that is hidden behind a "--static" flag.

FWIW, we've backported it in Gentoo safely and nothing exploded, so it should be okay for MSYS2 too.

What I think we really need/want is for packages to start using pkg-config for this, which does The Right Thing. I've considered making python-config fatal for some tests runs locally to try weed them out, but worried about the huge amount of work.

pkg-config --libs python-3.10 vs pkg-config --libs python-3.10 --static does what you'd expect.

[vstinner]

This PR is closed. If there is still a bug, please open a new issue at bugs.python.org ;-)

[MarshalX]

Will it be backported to 3.8 and 3.7?

[Arfrever]

Those branches accept almost only security fixes, so unfortunately probably no.

[vstinner]

Will it be backported to 3.8 and 3.7?

No, you have to backport this change downstream manually (yourself). Python 3.7 and 3.8 no longer accept bugfixes: https://devguide.python.org/#status-of-python-branches