Hi,
2011-12-04 15:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
I created a package for cryptographic functions as found in http://gnuwin32.sourceforge.net/packages/crypt.htm . You can get it from http://www.kortancegyesulet.hu/private/zoltan/mingw-crypt-2.14-1.fc16.src.rp...
Implementation details:
The main crypt-2.14.tar.gz source is only a skeleton that contains configure.ac, Makefile.am, etc.
The secondary source file (crypt.tar.gz) is the crypt directory from glibc-2.14.90-19 SRPM as in Fedora 16, you can compare them. GNUWin32's crypt.dll is a modified source from GLIBC 2.2.5.
crypt-mingw.patch contains
- 3 necessary private headers from glibc: sysdeps/i386/bits/byteswap.h sysdeps/x86_64/bits/byteswap.h sysdeps/x86_64/bits/wordsize.h
- a naive implementation for stpncpy(3) as the algorithm is described in the man page
and modifies the crypt source itself in a minimalistic was so it can compile standalone (e.g. there is no weak_alias(), and __THROW) and without warnings on both mingw32 and mingw64.
The result is libcrypt-1.dll (NOT crypt.dll as in GNUWin32), so when GLIBC adds more crypthographic functions, the library version can increase. All test programs (md5test.exe, md5c-test.exe, sha256test.exe, sha256c-test.exe, sha512test.exe, sha512c-test.exe, ufc.exe) report success with 0 return code.
New version at: http://www.kortancegyesulet.hu/private/zoltan/mingw-crypt-2.14-2.fc16.src.rp...
It turned out that the sha512 code and tests failed when compiled for 64-bit. The problem is that the glibc's sysdeps/x86_64/bits/byteswap.h use "long" computation in __bswap_64() and long is 32-bit when compiled for WIN64 so it breaks the 64-bit assumption of the macro, making it unsafe to use. The new version uses the i386 byteswap.h codes for both WIN32 and WIN64.
Best regards, Zoltán Böszörményi