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
[Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available #72689
The '_crypt' module provides a binding to the C crypt(3) function. It is used by the crypt.crypt() function.
Looking at the C code, there are a couple of things we can improve:
Because crypt() only depends on primitive C types, we currently get away with calling it without it being declared. Ensure that we include <unistd.h>, which is the POSIX header file declaring this.
The disadvantage of crypt() is that it's thread-unsafe. Systems like Linux and recent versions of FreeBSD nowadays provide crypt_r() as a replacement. This function allows you to pass in a 'crypt_data' object that will hold the resulting string for you. Extend the code to use this function when available.
This patch is actually needed to make this module build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). CloudABI's C library doesn't provide any thread-unsafe functions, meaning that crypt_r() is the only way you can crypt passwords.
I'm not sure performance matters. Modern crypt() algorithms should actually be slow enough (using a large number of rounds) to make brute-force attacks impractical...
Having looked at various implementations of crypt() and crypt_r(), I can't think of a reason why there would be any significant difference in performance. On systems like FreeBSD, crypt() is just a simple wrapper around crypt_r():
If there would be any difference in performance, it would also be astronomically small compared to the computation time spent by the cryptographic hash functions themselves.
New changeset a144fee by Gregory P. Smith (Miss Islington (bot)) in branch '3.7': bpo-28503: Use crypt_r() when available instead of crypt() (GH-11373) (GH-11376) a144fee
I'm going to close this as 3.7 and 3.8 are good now, but if someone wants to see the same thing done in 2.7 it should be possible for them make a PR. This is primarily just a configure.ac change.
Activity
EdSchouten commentedon Oct 22, 2016
The '_crypt' module provides a binding to the C crypt(3) function. It is used by the crypt.crypt() function.
Looking at the C code, there are a couple of things we can improve:
Because crypt() only depends on primitive C types, we currently get away with calling it without it being declared. Ensure that we include <unistd.h>, which is the POSIX header file declaring this.
The disadvantage of crypt() is that it's thread-unsafe. Systems like Linux and recent versions of FreeBSD nowadays provide crypt_r() as a replacement. This function allows you to pass in a 'crypt_data' object that will hold the resulting string for you. Extend the code to use this function when available.
This patch is actually needed to make this module build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). CloudABI's C library doesn't provide any thread-unsafe functions, meaning that crypt_r() is the only way you can crypt passwords.
serhiy-storchaka commentedon Oct 24, 2017
What is the performance of crypt_r() in comparison with crypt()?
pitrou commentedon Oct 25, 2017
I'm not sure performance matters. Modern crypt() algorithms should actually be slow enough (using a large number of rounds) to make brute-force attacks impractical...
EdSchouten commentedon Oct 25, 2017
Having looked at various implementations of crypt() and crypt_r(), I can't think of a reason why there would be any significant difference in performance. On systems like FreeBSD, crypt() is just a simple wrapper around crypt_r():
https://svnweb.freebsd.org/base/head/lib/libcrypt/crypt.c?view=markup#l134
If there would be any difference in performance, it would also be astronomically small compared to the computation time spent by the cryptographic hash functions themselves.
benjaminp commentedon Oct 26, 2017
This sgtm. Can you send a PR?
EdSchouten commentedon Dec 3, 2017
Ah, you folks switched to Git + Github in the mean time. Nice!
I've just sent this pull request: #4691
gpshead commentedon Dec 30, 2018
New changeset 387512c by Gregory P. Smith in branch 'master':
bpo-28503: Use crypt_r() when available instead of crypt() (GH-11373)
387512c
gpshead commentedon Dec 30, 2018
As this is internal only rather than a feature, i'll bring this into 3.7 as well.
gpshead commentedon Dec 31, 2018
New changeset a144fee by Gregory P. Smith (Miss Islington (bot)) in branch '3.7':
bpo-28503: Use crypt_r() when available instead of crypt() (GH-11373) (GH-11376)
a144fee
gpshead commentedon Dec 31, 2018
I'm going to close this as 3.7 and 3.8 are good now, but if someone wants to see the same thing done in 2.7 it should be possible for them make a PR. This is primarily just a configure.ac change.