"bug in glibc"

Server NGINX
1

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

2

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.

3

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