Re: [CVS] OpenSSL: OpenSSL_0_9_7-stable: openssl/util/ mkfiles.pl
If you wanna jinx someone, do it in CVS, eh? :-):-) In message [EMAIL PROTECTED] on Tue, 26 Oct 2004 15:01:39 +0200 (CEST), Dr. Stephen Henson [EMAIL PROTECTED] said: steve Log: steve Only add fips/dh once... - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #959] OpenSSL 0.9.7e fails to build with no-cast
E:\openssl-0.9.7e\out32openssl version -a OpenSSL 0.9.7e 25 Oct 2004 built on: Mon Oct 25 18:45:17 2004 platform: VC-WIN32 options: bn(64,32) rc4(idx,int) des(idx,cisc,4,long) compiler: cl /MT /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAM E_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_A SM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_RIPEMD -DOPENSSL_NO_MDC2 -DOPENSSL_NO_BF -DOPENSSL_NO_CAST -DOPENSS L_NO_KRB5 -DOPENSSL_NO_EC -DOPENSSL_NO_ENGINE -DOPENSSL_NO_HW OPENSSLDIR: /usr/local/ssl I believe OpenSSL fails to build with the above configuration, specifically the no-cast option seems to be the culprit. I'm using Visual C++ SP6 and the MASM extensions for building, the output from the compiler is: cl /Fotmp32\e_old.obj -Iinc32 -Itmp32 /MT /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_ WIN32 -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32 -DOPENSSL_NO_IDEA -DOP ENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_RIPEMD -DOPENSSL_NO_MDC2 -DOPENSSL_NO _BF -DOPENSSL_NO_CAST -DOPENSSL_NO_KRB5 -DOPENSSL_NO_EC -DOPENSSL_NO_ENGINE -DOP ENSSL_NO_HW -c .\crypto\evp\e_old.c e_old.c ..\crypto\evp\e_old.c(93) : error C2220: warning treated as error - no object fil e generated ..\crypto\evp\e_old.c(93) : warning C4013: 'EVP_cast5_cfb64' undefined; assuming extern returning int ..\crypto\evp\e_old.c(93) : warning C4047: 'return' : 'const struct evp_cipher_st *' differs in levels of indirection from 'int ' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. E:\openssl-0.9.7e Changing line 91 in e_old.c from #ifndef OPENSSL_NO_CAST5 to #ifndef OPENSSL_NO_CAST remedies the problem. Thanks, Austin Krauss SISCO, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
Here's a WAG: ldd the test binaries on the FC2 box -- it's possible they ended
up getting linked with the FC2 OpenSSL libs.
If that's not it, I'm out of ideas. :)
-Jack
On Wed, Oct 27, 2004 at 02:57:08PM +0200, Andreas M. Kirchwitz via RT wrote:
Hi OpenSSL team!
I downloaded the new OpenSSL 0.9.7e and compiled it on various
platforms. On Solaris 9 (SPARC) with GCC 3.2.3, everything is
fine.
On all my Linux boxes with Fedora Core 2 (Kernel 2.6.8,
GCC 3.3.3), make test fails after four of the
AES-256-CBC(encrypt/decrypt) tests as follows:
Testing cipher AES-256-CBC(encrypt/decrypt)
Key
60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
39 f2 33 69 a9 d9 ba cf a5 30 e2 63 04 23 14 61
Plaintext
f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
b2 eb 05 e2 c3 9b e9 fc da 6c 19 07 8c 6a 9d 1b
Can't find AES-128-CFB1
make[1]: *** [test_evp] Error 3
make[1]: Leaving directory `/usr/local/src/openssl-0.9.7e/test'
make: *** [tests] Error 2
Well, that doesn't mean much to me, but it obviously looks
like something I don't want to trust in.
OpenSSL 0.9.7d successfully completes the tests. (No wonder,
test/evptests.txt doesn't contain AES-128-CFB1 stuff. ;-)
Does it mean that OpenSSL is broken? Or does it mean that
the test procedure is broken in this respect?
Why does it work on the Solaris box?
Greetings, Andreas
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
Andreas M. Kirchwitz via RT wrote: Hi OpenSSL team! [...] OpenSSL 0.9.7d successfully completes the tests. (No wonder, test/evptests.txt doesn't contain AES-128-CFB1 stuff. ;-) Does it mean that OpenSSL is broken? Or does it mean that the test procedure is broken in this respect? Tests complete successfully on my test machines: - Linux box (Debian, Linux 2.4.27 SMP, 2 Xeon 3.2 Ghz CPU, gcc-3.0.4) - Linux box (RH 9, Linux 2.4.27#6 SMP i686 i686 i386 GNU/Linux, gcc-3.2.2-5) Probably another issue tied to Fedora ??? -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
Hello! Jack Lloyd via RT wrote: Here's a WAG: ldd the test binaries on the FC2 box -- it's possible they ended up getting linked with the FC2 OpenSSL libs. Checking the evp_test binary with ldd is a very good point and leads to an interesting result. On both, Solaris and Linux, ldd test/evp_test shows that it uses the installed OpenSSL package in /usr/local/ssl (my old OpenSSL 0.9.6d installation). But that's okay, and that's the reason why make test modifies LD_LIBRARY_PATH to contain the source directory (/usr/local/src/openssl-0.9.7e on my machine) so that evp_test uses the new library from there. On Solaris (where make test runs fine) this works as expected: env LD_LIBRARY_PATH=/usr/local/src/openssl-0.9.7e ldd test/evp_test libcrypto.so.0.9.7 = /usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7 ^^ On Linux (where make test fails) the wrong library is used: env LD_LIBRARY_PATH=/usr/local/src/openssl-0.9.7e ldd test/evp_test libcrypto.so.0.9.7 = /usr/local/ssl/lib/libcrypto.so.0.9.7 ^^^ (but /usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7 exists!) If I skip make test, do a make install (- /usr/local/ssl) and then run make test again (which now uses the freshly installed OpenSSL 0.9.7e instead of the previously installed OpenSSL 0.9.7d), the tests succeed! Funny, I work a lot on Solaris and Fedora systems, but I've never noticed that difference before. On Solaris, LD_LIBRARY_PATH seems to be searched _before_ any library pathes compiled into the binary. That's the usual way (as I know it). On Linux (or at least Fedora), LD_LIBRARY_PATH is searched _after_ any library pathes compiled into the binary. If I remove /usr/local/ssl, then env LD_LIBRARY_PATH=/usr/local/src/openssl-0.9.7e ldd test/evp_test finds /usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7. That's strange. I'm wondering if this is a special feature (security?) of Fedora Core 2 Linux or if this is now the default behaviour on Linux (with same or newer kernel/gcc/ld/ld.so etc.) If I use LD_PRELOAD instead of LD_LIBRARY_PATH, I can make evp_test use the correct library: env LD_PRELOAD=/usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7 ldd test/evp_test /usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7 = /usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7 (0x00784000) Thanks a lot for your hint with ldd. That different handling of LD_LIBRARY_PATH is something I didn't expect (so I've never checked if evp_test is really using the new library). Maybe the use of LD_PRELOAD is worth a thought to be put into the OpenSSL test procedures (make test). Again, thanks for your help! OpenSSL is great! Greetings, Andreas __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
In message [EMAIL PROTECTED] on Wed, 27 Oct 2004 17:18:35 +0200 (METDST), Andreas M. Kirchwitz via RT [EMAIL PROTECTED] said: Hi, I just found an email discussion that seems to cover what's happening to you: http://sources.redhat.com/ml/bug-glibc/2000-01/msg00046.html rt On Solaris, LD_LIBRARY_PATH seems to be searched _before_ any library rt pathes compiled into the binary. That's the usual way (as I know it). It seems like this wouldn't be the correct according to some specs, according to the email conversation I'm pointing at. rt On Linux (or at least Fedora), LD_LIBRARY_PATH is searched _after_ rt any library pathes compiled into the binary. If I remove /usr/local/ssl, rt then env LD_LIBRARY_PATH=/usr/local/src/openssl-0.9.7e ldd test/evp_test rt finds /usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7. rt rt That's strange. Yup, I've been bitten by the same for another project just recently, but didn't bother with it at the time. The question I have to you is if you have LD_RUN_PATH set in some way, or if you did something that sets -rpath when linking the libraries and applications. As I understand it, directories given with -rpath can't (and shouldn't, which makes sense) be overriden with LD_LIBRARY_PATH. rt Maybe the use of LD_PRELOAD is worth a thought to be put into the rt OpenSSL test procedures (make test). I'm thinking you're right. Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
In message [EMAIL PROTECTED] on Wed, 27 Oct 2004 17:18:35 +0200 (METDST), Andreas M. Kirchwitz via RT [EMAIL PROTECTED] said: Hi, I just found an email discussion that seems to cover what's happening to you: http://sources.redhat.com/ml/bug-glibc/2000-01/msg00046.html rt On Solaris, LD_LIBRARY_PATH seems to be searched _before_ any library rt pathes compiled into the binary. That's the usual way (as I know it). It seems like this wouldn't be the correct according to some specs, according to the email conversation I'm pointing at. rt On Linux (or at least Fedora), LD_LIBRARY_PATH is searched _after_ rt any library pathes compiled into the binary. If I remove /usr/local/ssl, rt then env LD_LIBRARY_PATH=/usr/local/src/openssl-0.9.7e ldd test/evp_test rt finds /usr/local/src/openssl-0.9.7e/libcrypto.so.0.9.7. rt rt That's strange. Yup, I've been bitten by the same for another project just recently, but didn't bother with it at the time. The question I have to you is if you have LD_RUN_PATH set in some way, or if you did something that sets -rpath when linking the libraries and applications. As I understand it, directories given with -rpath can't (and shouldn't, which makes sense) be overriden with LD_LIBRARY_PATH. rt Maybe the use of LD_PRELOAD is worth a thought to be put into the rt OpenSSL test procedures (make test). I'm thinking you're right. Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #961] typo in openssl.cnf
This may be old news, but there is a typo in openssl.cnf included with the latest version of openssl that will error out the cert creation. line 46 is: private_key = $dir/private/cakey.pem# The private key should be: private_key = $dir/private/cakey.pem # The private key I have seen quite a few posts regarding the error that openssl throws if this isn't corrected. Thanks for openssl!! scott __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
Andreas M. Kirchwitz via RT wrote: Hello! Richard Levitte - VMS Whacker via RT wrote: I just found an email discussion that seems to cover what's happening to you: http://sources.redhat.com/ml/bug-glibc/2000-01/msg00046.html Yeah, it seems like I'm hit by exactly the same issue. ;-) Ran in to this yesterday, where 0.9.7d was in the -rpath directory but was trying to build OpenSSH-3.9 that was testing if the OpenSSL headers matched the libs. The test had set LD_LIBRARY_PATH as expected to point to the new OpenSSL-0.9.7e. It worked on Solaris and newer HP_UX but failed on Linux and HP-UX 11.0. The man pages for ld on Linux say -rpath is used first. This is unfortunate as it means you can't build a number of different packages to be installed as a group, or even to test the newly built library. One of the problems is that different sub releases of OpenSSL use the same library names 0.9.7 where as a new release which adds functionality such as the AES-265-... should increment the library version. As it seems, Linux behaves this way for years. I'm really surprised that I've never noticed the difference before. But usually, I prefer to use -R/-rpath so that I don't need to set LD_LIBRARY_PATH at all. Maybe that's why it didn't matter for me so far. The question I have to you is if you have LD_RUN_PATH set in some way, or if you did something that sets -rpath when linking the libraries and applications. As I understand it, directories given with -rpath can't (and shouldn't, which makes sense) be overriden with LD_LIBRARY_PATH. Sorry that I didn't mention it earlier (that's typical for users, they always forget such important details ... shame on me ;-), yes, I did modify the variable EX_LIBS in the global Makefile (on Linux I add -L/usr/local/ssl/lib -Wl,--rpath=/usr/local/ssl/lib, -R/usr/local/ssl/lib on Solaris), otherwise libssl.so wouldn't find libcrypto.so. This sounds like a good reason at first sight, but turns out to be silly at second sight, because if somebody wants to use libssl.so he has to include /usr/local/ssl/lib anyway (thus, automatically finding libcrypto.so as well). I cannot exactly remember what it was, but one day this became an issue for some reason, otherwise it wouldn't have come to my attention (I usually don't do ldd on libraries as long as they work fine with the program they are linked to) and I wouldn't have put any effort in modifying the Makefile manually. But as said, I don't remember what issue made me do this. (It's the voices! The voices in my head make me do such things! ;-) I also could add /usr/local/ssl/lib to the system-wide search path for libraries, but I don't want the system binaries to use my OpenSSL, I only want to use it for my self-compiled software in /usr/local. Maybe the use of LD_PRELOAD is worth a thought to be put into the OpenSSL test procedures (make test). I'm thinking you're right. I have to admit, that my configuration seems to be some kind of weird at least. On the other hand, setting -R/-rpath/LD_RUN_PATH to a perfectly legal path like /usr/local/ssl/lib shouldn't break make test. However, thanks a lot for you answer. I'm happy, that nothing is really wrong, but that this different behaviour is by definition. ;-) Greetings, Andreas __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
In message [EMAIL PROTECTED] on Wed, 27 Oct 2004 15:43:57 -0500, Douglas E. Engert [EMAIL PROTECTED] said: deengert The man pages for ld on Linux say -rpath is used first. This deengert is unfortunate ... but makes sense from a security point of view (look up LD_LIBRARY_PATH with google and you'll see all the rants about it). deengert as it means you can't build a number of different packages deengert to be installed as a group, or even to test the newly built deengert library. I don't quite understand the argument that different packages wouldn't be possible to install as a group, can you elaborate? As to testing, I'm guessing LD_PRELOAD is your friend. I'm gonna do some tests around that. I'd like to know what Unix-like architectures do NOT support LD_PRELOAD, and what to do on those. deengert One of the problems is that different sub releases of deengert OpenSSL use the same library names 0.9.7 where as a new deengert release which adds functionality such as the AES-265-... deengert should increment the library version. There are differing opinions about that, but essentially, I agree. If a library pretends to be the same, an application using it shouldn't get this kind of surprise. The CFB1 cipher mode was brought on by the new FIPS functionality, which was prepared for 0.9.7, and tested as such. There were a number of powers involved, so to say... Oh well. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #961] typo in openssl.cnf
In message [EMAIL PROTECTED] on Wed, 27 Oct 2004 22:44:56 +0200 (METDST), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt This may be old news, but there is a typo in openssl.cnf included with rt the latest version of openssl that will error out the cert creation. rt rt line 46 is: rt private_key = $dir/private/cakey.pem# The private key rt rt should be: rt private_key = $dir/private/cakey.pem # The private key rt rt I have seen quite a few posts regarding the error that openssl throws if rt this isn't corrected. Eh, are you sure about this? On what platform? The reason I ask is that 1) the tests (make test) run well, at least on the machines where I have tested, and they do use apps/openssl.cnf, and 2) in the source, there's nothing that I can see that requires the comment starter to be preceeded with a whitespace. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
In message [EMAIL PROTECTED] on Wed, 27 Oct 2004 23:00:21 +0200 (CEST), Richard Levitte - VMS Whacker [EMAIL PROTECTED] said: richard deengert One of the problems is that different sub releases of richard deengert OpenSSL use the same library names 0.9.7 where as a new richard deengert release which adds functionality such as the AES-265-... richard deengert should increment the library version. richard richard There are differing opinions about that, but essentially, I agree. I'm gonna change my mind a bit. I think it should be OK for updates of the same library to include new functions. The trouble, at least on Linux, is that (as far as I know) it doesn't really look at the major and minor version number of the shared library, it goes for one specific name (as given with soname?). Of course, this leads to broken behavior, as an update of the library really should get a new (higher) minor version. On the other hand, we mishandle the possibility of differing minor version number as well... Ah well... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
