Subject: lib/10921: openssl should XX_LONG types to u_int32_t, not unsigned long
To: None <gnats-bugs@gnats.netbsd.org>
From: None <itojun@netbsd.org>
List: netbsd-bugs
Date: 08/31/2000 01:25:14
>Number: 10921
>Category: lib
>Synopsis: openssl build should XX_LONG types to u_int32_t, not unsigned long
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: lib-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Aug 31 01:26:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Jun-ichiro itojun Hagino
>Release: almost latest current (like 20000828)
>Organization:
itojun.org
>Environment:
NetBSD up1000 1.5E NetBSD 1.5E (UP1000) #18: Thu Aug 31 16:29:51 JST 2000 itojun@up1000:/export/up1000/home/itojun/NetBSD/src/sys/arch/alpha/compile/UP1000 alpha
>Description:
in crypto/dist/openssl, there are definitions like:
(sample: crypto/dist/openssl/crypto/bf/blowfish.h)
#define BF_LONG unsigned long
there are tons of #ifdef to determine the type to be used.
those XX_LONG types are not really meant to be "unsigned long",
they are assumed to be "unsigned 32bit integer".
if we compile the code on top of alpha (or other 64bit arch),
and if "unsigned long" is picked, the resulting code will not be
usable for realworld crypto application which tries to encrypt
bytestream on the memory.
these #ifdef can also lead to hard-to-track build failure for
third-party applications, as these headers will be installed into
/usr/include/openssl. userland program can #define any random symbols,
and those random symbols can affect the declaration of XX_LONG.
if the declaration of XX_LONG mismatches between libcrypto and
application, any random failure can happen.
>How-To-Repeat:
>Fix:
modify all openssl header files, and remove unnecessary #defines.
if unsigned 32bit integer is required, use u_int32_t.
use "#ifdef __alpha__" or "#if ALIGNBYTES > 1" when we need
to determine alignment constraints and other things.
(see the latest sys/crypto)
>Release-Note:
>Audit-Trail:
>Unformatted: