There is a note in src/os/unix/ngx_user.c about a bug in glibc for
crypt_r:
/* work around the glibc bug */
cd.current_salt[0] = ~salt[0];
value = crypt_r((char *) key, (char *) salt, &cd);
I was wondering if anyone knew what the bug was, as I am running on a
platform (Musl libc) that has got NGX_HAVE_GNU_CRYPT_R but has a
different
implementation, in particular has no current_salt field in struct
crypt_data (and indeed the man page says you should treat it as opaque
except for the initialized field).
I was wondering exactly what the bug was as then I could write a test
for
it rather than always including this code; I have not been able to find
it
in the glibc bug tracker though.
Thanks
Justin
On Mar 31, 2013, at 14:33 , Justin Cormack wrote:
There is a note in src/os/unix/ngx_user.c about a bug in glibc for crypt_r:
/* work around the glibc bug */
cd.current_salt[0] = ~salt[0];
value = crypt_r((char *) key, (char *) salt, &cd);
I was wondering if anyone knew what the bug was, as I am running on a platform
(Musl libc) that has got NGX_HAVE_GNU_CRYPT_R but has a different implementation,
in particular has no current_salt field in struct crypt_data (and indeed the man
page says you should treat it as opaque except for the initialized field).
I was wondering exactly what the bug was as then I could write a test for it
rather than always including this code; I have not been able to find it in the
glibc bug tracker though.
2002-10-29 Daniel Jacobowitz [email protected]
- crypt/crypt_util.c (__init_des_r): Initialize current_salt
and current_saltbits.
https://groups.google.com/forum/?fromgroups=#!topic/linux.debian.maint.glibc/Q88bwAp222w
–
Igor S.
On Sun, Mar 31, 2013 at 4:12 PM, Igor S. [email protected] wrote:
I was wondering if anyone knew what the bug was, as I am running on a
2002-10-29 Daniel Jacobowitz [email protected]
* crypt/crypt_util.c (__init_des_r): Initialize current_salt
and current_saltbits.
https://groups.google.com/forum/?fromgroups=#!topic/linux.debian.maint.glibc/Q88bwAp222w
Ok I just checked and this bug was fixed in glibc-2.3.2, which was
released
in March 2003… Any chance of removing the workaround as it is relying
on
fields that may not exist and are implementation internal?
Justin