New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypt.h should be in _cryptmodule.c, not in public header #88914
Comments
In bpo-32635, it was discovered that _cryptmodule.c was missing a dependency on crypt.h, which caused it to segfault when it was missing the proper prototype for crypt. This was fixed by adding an #include <crypt.h> to Python.h. This include doesn't need to be in the public header; it only needs to be in _cryptmodule.c. Removing it from the public header is helpful for packagers, because it means that the libpython-dev (or whatever) package doesn't need a dependency on libcrypt-dev, only on the libcrypt runtime library. |
Could you backport this fix to at least 3.9 and 3.10 branches? |
Done.
I'm not sure what you mean. In Python 2.7 and Python 3.6, <crypt.h> was already included by Include/Python.h: #ifdef HAVE_CRYPT_H
#include <crypt.h>
#endif |
See issue bpo-32635, where Victor Stinner backported some commit (with problematic location of '#include <crypt.h>') to 2.7 and 3.6 branches (which was released in >=2.7.15 and >=3.6). |
crypt.h was added to Python.h by: https://github.com/python/cpython/pull/5284/files And this change was then backported to 2.7 and 3.6. Ok, now I understand. Well, it's now fixed in all branches accepting bugfixes. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: