On Sun, Mar 31, 2013 at 4:12 PM, Igor Sysoev <[email protected]> wrote: > 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 > > 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
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
