Richard Levitte [Thu, 14 Oct 2004 05:49:01 +0000 (05:49 +0000)]
Because libraries on Windows lack useful version information, the zlib
guys had to change the name to differentiate with older versions when
a backward incompatibility came up. Of course, we need to adapt.
This change simply tries to load the library through the newer name
(ZLIB1) first, and if that fails, it tries the good old ZLIB.
Andy Polyakov [Tue, 28 Sep 2004 20:52:14 +0000 (20:52 +0000)]
Fix Solaris 10_x86 shared build. -Bsymbolic is required to avoid
"remaining relocations" in assembler modules. The latter seems to
be new behaviour, elder as/ld managed to resolve this relocations
as internal. It's possible to address this problem differently,
but I settle for -Bsymbolic...
PR: 946
ASN1_STRING_to_UTF8() assumed that the MBSTRING_* flags were of
the form MBSTRING_FLAG|nbyte where "nbyte" is the number of
bytes per character.
Unfortunately this isn't so and we can't change the #defines because
this would break binary compatibility, so for 0.9.7X only translate
between the two.
Richard Levitte [Mon, 6 Sep 2004 14:21:14 +0000 (14:21 +0000)]
num is an unsigned long, but since it was transfered from
crypto/sha/sha_locl.h, where it is in fact an int, we need to check
for less-than-zero as if it was an int...
Richard Levitte [Fri, 30 Jul 2004 14:38:02 +0000 (14:38 +0000)]
To protect FIPS-related global variables, add locking mechanisms
around them.
NOTE: because two new locks are added, this adds potential binary
incompatibility with earlier versions in the 0.9.7 series. However,
those locks will only ever be touched when FIPS_mode_set() is called
and after, thanks to a variable that's only changed from 0 to 1 once
(when FIPS_mode_set() is called). So basically, as long as FIPS mode
hasn't been engaged explicitely by the calling application, the new
locks are treated as if they didn't exist at all, thus not becoming a
problem. Applications that are built or rebuilt to use FIPS
functionality will need to be recompiled in any case, thus not being a
problem either.
Andy Polyakov [Sat, 24 Jul 2004 13:40:47 +0000 (13:40 +0000)]
Add casts where casts due. It's "safe" to cast, because "wrong" casts
will either be optimized away or never performed. The trouble is that
compiler first parses code, then optimizes, not both at once...
Andy Polyakov [Sat, 17 Jul 2004 12:54:54 +0000 (12:54 +0000)]
IA-64 is intolerant to misaligned access. It was a problem on Win64 as
we were mislead by _MSC_VER macro, which is defined by *all* Windows
Microsoft compilers.
Richard Levitte [Thu, 8 Jul 2004 08:32:51 +0000 (08:32 +0000)]
o_str.c: Windows doesn't have <strings.h>, and since we use _strnicmp() and
_stricmp() on that platform, use the appropriate header file for it,
<string.h>.
o_str.h: we only want to get size_t, which is defined in <stddef.h>.
Philippe Bougeret <philippe.bougeret@freesbee.fr> notified us about Windows
not having a <strings.h>
Richard Levitte [Thu, 1 Jul 2004 12:33:44 +0000 (12:33 +0000)]
Explain a little better what BN_num_bits() and BN_num_bits_word() do.
Add a note as to how these functions do not always return the key size, and
how one can deal with that.
Richard Levitte [Mon, 21 Jun 2004 09:07:41 +0000 (09:07 +0000)]
Make sure we don't try to loop over an empty EXHEADER. In the
Makefiles where this was fixed by commenting away code, change it to
check for an empty EXHEADER instead, so we have less hassle in a
future where EXHEADER changes.
Andy Polyakov [Mon, 17 May 2004 15:37:26 +0000 (15:37 +0000)]
Make reservations in FIPS code for upcoming size_t-fication of OpenSSL API.
And couple of bug-fixes in fips/rand code [return without lock release and
incorrect return value in fips_rand_bytes].