Re: status of support sparc64 on linux
I just changed ./Configure line: #linux64-sparcv9,sparc64-linux-gcc:-m64 -mcpu=v9 -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DBN_DIV2W::-D_REENTRANT:ULTRASPARC::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, by linux64-sparcv9,gcc:-m64 -mcpu=v9 -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DBN_DIV2W::-D_REENTRANT:ULTRASPARC::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, Change to: linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, configured with: ./Configure linux64-sparcv9 shared no-asm ^^ You can't use that (it's rather meaningless to attempt) in the lack of appropriate flags in the config line. Get rid of no-asm too... make is ok, but make test fail: ... test BN_sqr Square test failed! That's because BN_LLONG makes compiler believe that sizeof(long long)==16. gcc is 2.96(RedHat) glibc 2.2.5 (32 64 bits). Huh? 2.96(RedHat) supports -m64? What's default ABI? Run 'gcc -v -E -x c /dev/null'. Do you see __arch64__? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #375] Gcc bug triggered in PEM_get_EVP_CIPHER_INFO()
I've fixed the problem by adding a section in the PROBLEMS file. I
see no reason to support a buggy compiler by changing the OpenSSL code.
Ths ticket is now resolved.
[[EMAIL PROTECTED] - Tue Dec 3 14:17:08 2002]:
Seeing the bugs directory in the openssl tarball, I thought you
might be interested to know that gcc-3.0 contains a bug that is
triggered in the PEM_get_EVP_CIPHER_INFO() function...
Here is the problem:
$ ssh-keygen -t rsa -N abcde
then
$ ssh-keygen -t rsa -P abcde -p
should works, but it didn't on my system (gcc-3.0, OpenSSH_3.4p1,
OpenSSL 0x00907004).
I have traced down the problem to PEM_get_EVP_CIPHER_INFO(): gcc-3.0
generates invalid assembler for this function. Just look at the
machine
code that corresponds to this C code:
header+=11;
if (*header != '4') return(0); header++;
if (*header != ',') return(0); header++;
And you will notice that %eax (that represents header) is
incremented
too many times...
A more insightful demonstration of this bug is also available in the
`gcc-3.0-bug-demo.c' file.
--
/*
** Gcc-3.0 bug -- noticed by Marc Bevand bevand_m (at) epita.fr
** on Tue Dec 3 14:06:02 CET 2002
**
** All is right with -fPIC -O1, the bug only occurs with -fPIC
** -O[23]:
**
**$ gcc -fPIC -O1 gcc-3.0-bug-demo.c
**$ ./a.out
**all is right
**$ gcc -fPIC -O2 gcc-3.0-bug-demo.c
**$ ./a.out
**there is a *bug*
**
** Look at the assembler generated for the 2 lines marked with XXX in
** foobar():
**
** 80484e3: 8b 45 08mov0x8(%ebp),%eax
** 80484e6: 83 c0 02add$0x2,%eax
** 80484e9: 89 45 08mov%eax,0x8(%ebp)
** 80484ec: 80 78 02 63 cmpb $0x63,0x2(%eax)
**
** The value of header, contained in 0x8(%ebp), should be
incremented
** only 1 time, but actually it is incremented 2 times (in add and
** cmpb).
*/
int hello(char **notused)
{
return 0;
}
int foobar(char *header)
{
if (strncmp(header, ab, 2))
return 0;
header += 2; /* XXX */
if (*header != 'c') /* XXX */
return 0;
if (hello(header))
return 0;
return 1;
}
int main(void)
{
if (foobar(abc__))
puts(all is right);
else
puts(there is a *bug*);
return 0;
}
--
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
In message [EMAIL PROTECTED] on Wed, 04 Dec 2002 09:08:07 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 appro -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG appro RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, Hmm, I assume we can make that change in Configure, eh? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
Using the lynx browser compiled with openssl, the environment variable SSL_CERT_FLLE seems to be ignored. If I place the trusted root certificates in the default location, the application finds them without difficulty. If placed in a non-default location, setting the value of SSL_CERT_FILE to that location doesn't allow the certificates to be read in. I recently noted this with the 20021115 snapshot of openssl 0.9.7. I now see that a similar report was noted earlier on the lynx-dev mailing list with a proposed patch for openssl 0.9.6g by Takeshi Hataguchi (see: http://www.flora.org/lynx-dev/html/month102002/msg00057.html;). Applying that patch to 0.9.7 led to a failure in make test, so it may not be the appropriate patch. I don't remember seeing this discussion on openssl-dev. Could someone verify independently that SSL_CERT_FILE doesn't allow reading certificates in non-default locations? If verified, can someone familiar with how this is supposed to work come up with a patch? The code for this is in crypto/x509/by_file.c, with similar code for SSL_CERT_DIR in crypto/x509/by_dir.c (with associated code in crypto/x509/x509_def.c and crypto/cryptlib.h). If this is really a problem with the application, let me know and I will take the problem back to the lynx-dev mailing list. Thanks. Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
On Tue, 3 Dec 2002, Doug Kaufman wrote: Using the lynx browser compiled with openssl, the environment variable SSL_CERT_FLLE seems to be ignored. If I place the trusted root certificates in the default location, the application finds them without difficulty. If placed in a non-default location, setting the value of SSL_CERT_FILE to that location doesn't allow the certificates to be read in. I recently noted this with the Replying to my own post. I see that there was a similar discussion more than a year ago on openssl-dev. Please see the post by Steve Henson. Is this the same problem that never got fixed? http://www.mail-archive.com/openssl-dev@openssl.org/msg09920.html; Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
appro linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 appro -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG appro RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, Hmm, I assume we can make that change in Configure, eh? My idea was to hear if it passes 'make test' first. Then add shared related flags and see if it still passes the test. *Then* add it to ./Configure as well as uncomment corresponding section in ./config... A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSLv2 Session ID bug
Hi, While using openssl to test caching of session id's, I noticed that the session id of SSLv2 is not being extracted out of the message correctly. The spec (http://wp.netscape.com/eng/security/SSL_2.html) says that the server_finished message is of the following format: char MSG-SERVER-FINISHED char SESSION-ID-DATA[N-1] Where MSG-SERVER-FINISHED is specified as 0x06. When I do $ openssl s_client -ssl2 -connect www.openssl.org:443 then the openssl _always_ reports the session id as starting with 0x06, which is clearly not correct. It would appear that the SSLv2 code is not correctly skipping over the MSG-SERVER-FINISHED char. Cheers Crispin Flowerday PS. Please CC any replies to me as I am not on the list. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and0.9.6
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Could someone verify independently that SSL_CERT_FILE doesn't rt allow reading certificates in non-default locations? I can verify, by looking at the code, that SSL_CERT_FILE should work, but only if the default cert file (/usr/local/ssl/cer.pem?) doesn't exist or is faulty. Basically, the system default seems to have precedence... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Could someone verify independently that SSL_CERT_FILE doesn't rt allow reading certificates in non-default locations? I can verify, by looking at the code, that SSL_CERT_FILE should work, but only if the default cert file (/usr/local/ssl/cer.pem?) doesn't exist or is faulty. Basically, the system default seems to have precedence... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #377] SSLv2 Session ID bug
Hi, While using openssl to test caching of session id's, I noticed that the session id of SSLv2 is not being extracted out of the message correctly. The spec (http://wp.netscape.com/eng/security/SSL_2.html) says that the server_finished message is of the following format: char MSG-SERVER-FINISHED char SESSION-ID-DATA[N-1] Where MSG-SERVER-FINISHED is specified as 0x06. When I do $ openssl s_client -ssl2 -connect www.openssl.org:443 then the openssl _always_ reports the session id as starting with 0x06, which is clearly not correct. It would appear that the SSLv2 code is not correctly skipping over the MSG-SERVER-FINISHED char. Cheers Crispin Flowerday PS. Please CC any replies to me as I am not on the list. __ 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]
[openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz
Mark has kindly reported that the latest vms.mar works as expected on VAX. This ticket is therefore resolved. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #328] DH_compute_key incompatable with PKCS #3
I haven't heard any news about this. I also mailed ietf-tls asking about this, but had no response there either. That means there will most probably be no fix in 0.9.6h. 0.9.7 still has a week... I think I'll change the miestone for this fix. [[EMAIL PROTECTED] - Thu Nov 14 19:05:29 2002]: In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
IMPORTANT: Changed release dates, and a plea for testers
[Note: for any time or time range given here, please assume swedish time. If you live in a different timezone, please adjust the time range appropriately] Due to lack of time and a few last bug fixes to review, I'm moving the release of 0.9.7 beta 5 to the evening of thursday 2002-12-05. Also, I'm not exactly sure beta5 will be considered final, so I've made space for a 6th beta, to be release on thursday 2002-12-12 (in the evening), and the final release on tuesday 2002-12-17 (in the morning). Simultaneously, I'll release 0.9.6h, which will be the last release of the 0.9.6 branch. Any bugs found there after that will be fixed in the 0.9.7 branch only. Please try the 0.9.6 snapshots *today* or during the day tomorrow. Quick bug fixes will be honored, others will only be applied to the 0.9.7 branch. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
NOTICE: OpenSSL Request Tracker unavailable Dec 6-9
NOTICE: Due to major works on the electrical power system in the university's computer center on Dec 7 and 8 (Saturday, Sunday), the campus of BTU Cottbus, Germany, cannot be reached from Friday evening, Dec 6, to Monday morning, Dec 9 (shutdown and restart of the central router(s) by the operators). The OpenSSL.org request tracker, which is located on www.aet.tu-cottbus.de therefore will be unreachable during that time, including both the web-interface and the mail interface. www.aet.tu-cottbus.de itself is not affected by the power shutdown, but cannot be reached as long as the campus network infrastructure is down. This notice _only_ applies to the OpenSSL Request Tracker. The rest of the OpenSSL.org infrastructure are located at ETH Zurich, Switzerland. Sincere regards, Lutz Jänicke -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #348] [PATCH] supporting the x86_64 architecture
Patch applied and committed. This ticket is now resolved. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #347] DJGPP patch for openssl-0.9.7
Applied after having remove the dependencies on GNU make. This ticket is now resolved. [[EMAIL PROTECTED] - Tue Nov 19 16:46:24 2002]: The following patch allows openssl-0.9.7 to compile under DJGPP. The process was broken by two recent changes. Gisle's patch left out some required headers. The changes for Cygwin added PATH directives incompatible with the DJGPP path separator of ; rather than :. In addition there seems to be an error in ectest.c. That file is run from the test subdirectory. The FLAT_INC portion of the code doesn't work under DJGPP, and I am not sure how it would under other platforms (referring to ../.. when it is one directory under the top directory). None of the other test files which include e_os.h use this construction. I would think that either all need it, or none of them. I also changed INSTALL.DJGPP to reflect the need to put WATT_ROOT in the environment prior to configuring. I am attaching the patch, since it has long lines that would get munged in the archives. Since I am in the US, I am also sending a copy to the US government site. With the new regulations, it doesn't appear that I can just send a copy of this email. Look for a copy of my notification in openssl-dev with subject TSU Request - encryption. The patch is against the 20001115 snapshot. After applying tha patch, there are no warnings with make depend, make, make test, or make install. This was only tested with Configure no-threads no-idea no- rc5 no-mdc2 386 --prefix=/dev/env/DJDIR DJGPP. Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #378] building without md5
System and version: --- OpenSSL 0.9.7 BETA 4 Host: Debian woody (3.0) Type: - Building , Configuration error Description: when configuring openssl with: './config -no-md5' make depend fails because it includes 'md5.h' in 'test/hmactest.c' and 'ssl/s3_srvr.c' Reproduction: - $ ./config -no-md5 $ make depend Failure message: ../util/domd .. -MD gcc -- -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MD5 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_TLS1 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=k6 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -I.. -I../include -DOPENSSL_NO_MD5 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_TLS1 -- bntest.c ectest.c ideatest.c md2test.c md4test.c md5test.c hmactest.c rc2test.c rc4test.c rc5test.c destest.c shatest.c sha1test.c mdc2test.c rmdtest.c randtest.c dhtest.c enginetest.c casttest.c bftest.c ssltest.c dsatest.c exptest.c rsa_test.c evp_test.c In file included from hmactest.c:71: ../include/openssl/md5.h:67: #error MD5 is disabled. make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7-beta4/test' making dependencies tools... make[1]: Entering directory `/home/chris/src/diff/openssl-0.9.7-beta4/tools' make[1]: Nothing to be done for `depend'. make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7-beta4/tools' $ ./config -no-md5 -no-hmac $ make depend $ make Failure message: In file included from s3_srvr.c:125: ../include/openssl/md5.h:67: #error MD5 is disabled. make[1]: *** [s3_srvr.o] Error 1 make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7-beta4/ssl' make: *** [sub_all] Error 1 Regards Christian -- [EMAIL PROTECTED]Innominate Security Technologies AG software engineer networking people tel: +49.30.6392-3300 http://www.innominate.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #379] ssltest.c build breaks in 0.9.7-stable on Solaris/x86 with GCC
ssltest.c doesn't currently build (from 0.9.7-stable branch) with GCC 2.95.x on Solaris/x86 platforms; failures are like: gcc -I.. -I../include -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -O3 -fomit-frame-pointer -m486 -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c ssltest.c In file included from ../include/openssl/bio.h:65, from ssltest.c:128: /usr/local/lib/gcc-lib/i386-pc-solaris2.6/2.95.3/include/stdarg.h:170: conflicting types for `va_list' /usr/include/stdio.h:90: previous declaration of `va_list' *** Error code 1 The #define _XOPEN_SOURCE 600 is the culprit, it seems, which is for Linux systems apparently. The glibc unistd.h I have defines gethostname on this conditional: #if defined __USE_BSD || defined __USE_XOPEN2K so the attached patch seems like a reasonable fix. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #380] VC-WIN32 build issue
testing with openssl-0.9.7-stable-SNAP-20021203 ... in util/pl/VC-32.pl there is a line $lib_cflag= -D_WINDLL -D_DLL; which causes problems if the /MT option in $cflags is changed to /MT (solution is to remove the -D_DLL in this senario). since according to the help for VC7, /MD also defines _DLL the -D_DLL is unnecssary. (I think this is also the case in VC4-VC6) therefore I suggest just removing the -D_DLL permantly, so if somebody changes the /MD to /MT they dont have to spend ages working out why it doesnt link. Louis Solomon www.SteelBytes.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #381] [PATCH] for openssl-0.9.7-beta4 to fix some bugs in the chil engine code (hw_ncipher.c)
Whilst conducting some testing with OpenSSL 0.9.7beta4 and the nCipher chil plugin, I observed the following issues: 1. Lack of threadsafety if app fails to support new OpenSSL dynamic locks At the moment hw_ncipher.c uses the new OpenSSL dynamic lock code inorder to implement the hwcrhk locking upcalls. However if the OpenSSL application fails to implement the dynamic upcalls, i.e. CRYPTO_get_dynlock_create_callback() returns NULL, then the hwcrhk engine code becomes non threadsafe. This is a serious problem given that it is unlikely that existing applications such as apache will implement dynamic upcalls anytime soon, after all OpenSSL dynamic locks are only required by hw_ncipher.c at the moment. Here are some errors from apache when configured using --with-mpm=worker and with SSLCryptoDevice chil set in ssl.conf. [Thu Nov 28 15:53:11 2002] [notice] Apache/2.0.43 (Unix) mod_ssl/2.0.43 \ OpenSSL/0.9.7-beta4 configured -- resuming normal operations httpd: ../setup.c:472: nfast_hwch_doneconnection: Assertion `hwctx-conn\ datas[remember].inuse 0' failed. [Thu Nov 28 15:56:31 2002] [notice] child pid 17526 exit signal Aborted \ (6) httpd: ../setup.c:472: nfast_hwch_doneconnection: Assertion `hwctx-conn\ datas[remember].inuse 0' failed. httpd: ../setup.c:472: nfast_hwch_doneconnection: Assertion `hwctx-conn\ datas[remember].inuse 0' failed. httpd: ../setup.c:472: nfast_hwch_doneconnection: Assertion `hwctx-conn\ datas[remember].inuse 0' failed. There is a simple workaround that one can use in hw_ncipher.c to support multithreaded programs in the case when only static locks are supported by the application. The workaround use the maxmutexes member of HWCryptoHook_InitInfo to configure the hwcrhk library to only ever request one lock context. This workaround is contained in the patch. 2. Missing emsg in call to p_hwcrhk_ModExpCRT() in hw_ncipher.c The p_hwcrhk_ModExpCRT() function call made in hwcrhk_rsa_mod_exp() forgets to pass in emsg as the last argument. This means that errors messages from chil occuring in this function are lost. This bug is fixed in the patch. 3. hwcrhk_log_message() in hw_ncipher.c This fails to write a newline character to the logstream after each log message. So for instance setting debug in s_client produces: $ ./openssl s_client -engine chil -debug -connect localhost:443 [12370] Loading nfhwch 1.5 flags=0010 bignums=4ll mutexes getpas\ sphrase getphystoken maxmutexes=1 maxsimultaneous=1000 (hwcrhk 1.5.0\ cam1 hwcrhk/build 2.0.6cam1 hwcrhk/nfast 1.77.9cam1 hwcrhk/nfast/bui\ ld 2.0.6cam1 hwcrhk/sworld 1.14.3cam1 hwcrhk/sworld/build 2.0.6cam1 \ hwcrhk/sworld/nfast 1.77.9cam1 hwcrhk/sworld/nfast/build 2.0.6cam1)n\ Cipher nFast HWCryptoHook 1.5engine chil set. CONNECTED(0004) write to 08181FE8 [08182040] (148 bytes = 148 (0x94)) - 80 92 01 03 01 00 69 00-00 00 20 00 00 39 00 00 ..i... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5 0020 - 00 00 33 00 00 32 00 00-2f 00 00 07 05 00 80 03 ..3..2../... 0030 - 00 80 00 00 66 00 00 05-00 00 04 01 00 80 08 00 f... 0040 - 80 00 00 63 00 00 62 00-00 61 00 00 15 00 00 12 ...c..b..a.. 0050 - 00 00 09 06 00 40 00 00-65 00 00 64 00 00 60 00 .@..e..d..`. 0060 - 00 14 00 00 11 00 00 08-00 00 06 04 00 80 00 00 0070 - 03 02 00 80 86 a5 6b 75-67 16 d1 78 3d 13 c9 62 ..kug..x=..b 0080 - 6e 84 8e ff ff 05 d9 ee-cf d3 5e 0e f4 59 56 23 n.^..YV# 0090 - e9 5d 2d 5b .]-[ ... This bug is fixed in the patch. 4. hwcrhk_insert_card() in hw_ncipher.c $ createocs 1 0 testcardset 1 0 Insert new operator card 1 into module 1 slot 0 and press return... Passphrase for new operator card 1: NO PASSPHRASE cardset created; hkltu = a0f043a70b4f2fd9392149f95390b273e7f72f50 $ generatekey --batch hwcrhk ident=testkey nCipher KM key generation/import utility key generation/import parameter(s): protect Protected by TOKEN ident Key identifier testkey typeKey type RSA sizeKey size 1024 paramsreadfile Group parameters file (DH only) recoveryRecovery feature 1 Using Operator Card Set `testcardset'. Loaded Operator Card Set, using card #1. Generating fresh key ... Key generated and stored. NOW TAKE THE CARDSET OUT OF THE HSM'S SLOT $ ./openssl req -engine chil -keyform ENGINE -key testkey -new engine chil set. unable to load Private Key 12099:error:2806D069:lib(40):GENERAL_ALLOCATE_PROMPT:no result buffer:ui_lib.c:150: 12099:error:81069066:hwcrhk engine:HWCRHK_LOAD_PRIVKEY:chil error:hw_ncipher.c:792:Failed to load key (codes: m1b0s0SE m1b0s1SE m1b0s0SE m1b0s1SE m1b0CN-1 m1BN) 12099:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:117: The bug is in the following code: int
[openssl.org #382] building without rc4 fails
System and version: --- OpenSSL 0.9.7 BETA 4 Host: Debian woody (3.0) Type: - Building , Configuration error Description: when configuring openssl with: './config -no-rc4' make fails because it includes 'rc4.h' in 'crypto/engine/eng_openssl.c' Reproduction: - $ rm -rf openssl-0.9.7-beta4 $ tar zxf openssl-0.9.7-beta4.tar.gz $ cd openssl-0.9.7-beta4 $ ./config -no-rc4 $ make depend $ make Failure message: make[2]: Entering directory `/home/chris/src/diff/openssl-0.9.7-beta4/crypto/engine' gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_RC4 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=k6 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c -o eng_openssl.o eng_openssl.c In file included from eng_openssl.c:184: ../../include/openssl/rc4.h:63: #error RC4 is disabled. make[2]: *** [eng_openssl.o] Error 1 make[2]: Leaving directory `/home/chris/src/diff/openssl-0.9.7-beta4/crypto/engine' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7-beta4/crypto' make: *** [sub_all] Error 1 Regards Christian -- [EMAIL PROTECTED]Innominate Security Technologies AG software engineer networking people tel: +49.30.6392-3300 http://www.innominate.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #383] crash bug with openssl-0.9.7-stable-SNAP-20021203 on Win32
build commands used (from a VS.NET command shell) set path=%path%;c:\cygwin\bin perl Configure VC-WIN32 threads zlib no-shared ms\do_masm.bat nmake -f ms\ntdll.mak then drop the dlls from out32dll into an existing project, and it crashes. openssl-0.9.6g compiled with exactly the same steps, works ok. test platform winxp pro sp1 dual P3/733 + 640MB VS.NET crash details when build with in debug mode (added debug to the mk1mf.pl lines in ms\do_masm.bat) file ssl_sess.c, line 681 i=tp.cache-down_load; but tp.cache == 0x ! hence the crash. call stack func SSL_CTX_flush_sessions, file ssl_sess.c, line 681 func SSL_CTX_free, file ssl_lib.c, line 1425 func SSL_free, file ssl_lib.c, line 469 how to make it crash ... hmm, good question. just using the openssl command line tool to connect to itself didnt cause it. so how am I doing it evertime ? read on ... download porttunnel from www.steelbytes.com and install it stick libeay32.dll and ssleay32.dll in the porttunnel program folder make two mappings in porttunnel with the following info mapping one: listen on 0.0.0.0:80 and redirects to 127.0.0.1:81 ssl_method_23 and cypher ALL:@STRENGTH selected in between porttunnel and server mapping two: listen on 127.0.0.1:81 and redirects to target.server.com:80 ssl_method_23 and cypher ALL:@STRENGTH selected in between client and porttunnel start porttunnel telnet to localhost:80 type a bit of crap, and it crashes everytime contact me for any other crash info requried. (happens everytime. I've re downloaded 0.9.6g and openssl-0.9.7-stable-SNAP-20021203 adn recompiled both etc, and yes 0.9.7 still crashes and 0.9.6 still doesnt) Louis Solomon www.SteelBytes.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
Andy Polyakov wrote: ... Change to: linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, all test passed (./Configure linux64-sparcv9 no-asm without no-asm). ... Huh? 2.96(RedHat) supports -m64? What's default ABI? Run 'gcc -v -E -x c /dev/null'. Do you see __arch64__? I need to spec -m64 to get __arch64__ # gcc -v -E -x c /dev/null Reading specs from /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-112) /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -D_LONGLONG -D__sparc__ -Dlinux -D__ELF__ -D__unix__ -D_LONGLONG -D__sparc__ -D__linux__ -D__unix -D__linux -Asystem(unix) -Asystem(posix) -D__NO_INLINE__ -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) /dev/null GNU CPP version 2.96 2731 (Red Hat Linux 7.3 2.96-112) (cpplib) (sparc64 GNU/Linux with ELF) ignoring nonexistent directory /usr/sparc64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/include /usr/include End of search list. # gcc -m64 -v -E -x c /dev/null Reading specs from /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-112) /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -D_LONGLONG -D__sparc__ -Dlinux -D__ELF__ -D__unix__ -D_LONGLONG -D__sparc__ -D__linux__ -D__unix -D__linux -Asystem(unix) -Asystem(posix) -D__NO_INLINE__ -D__SIZE_TYPE__=long unsigned int -D__PTRDIFF_TYPE__=long int -D__arch64__ -Acpu(sparc64) -Amachine(sparc64) /dev/null GNU CPP version 2.96 2731 (Red Hat Linux 7.3 2.96-112) (cpplib) (sparc64 GNU/Linux with ELF) ignoring nonexistent directory /usr/sparc64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/include /usr/include End of search list. Ricardo.- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, all test passed (./Configure linux64-sparcv9 no-asm without no-asm). Next step is to add shared lib bits. Therefore change to: linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR), and then './Configure linux64-sparcv9 shared' and finally 'make'. Does it build? What does 'ldd apps/openssl' return? Does 'make test' pass? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
I asked Eric Rescorla, and he agreed the section of the TLS RFC was definitely unclear, but he wasn't totally sure which way it should go as far as stripping any leading 0s before using the shared secret to generate keys. It basically depends on what various implementations have decided to do. -J On Wed, 4 Dec 2002, Richard Levitte via RT wrote: I haven't heard any news about this. I also mailed ietf-tls asking about this, but had no response there either. That means there will most probably be no fix in 0.9.6h. 0.9.7 still has a week... I think I'll change the miestone for this fix. [[EMAIL PROTECTED] - Thu Nov 14 19:05:29 2002]: In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Could someone verify independently that SSL_CERT_FILE doesn't rt allow reading certificates in non-default locations? I can verify, by looking at the code, that SSL_CERT_FILE should work, but only if the default cert file (/usr/local/ssl/cer.pem?) doesn't exist or is faulty. Basically, the system default seems to have precedence... Yes, it _should_ work, but it doesn't. I have tested with no file in the system default location, and the file pointed to by SSL_CERT_FILE still doesn't get read. A non-existent file shouldn't take precedence over an existing file. Even in the case of an existing default file, what would be the purpose of SSL_CERT_FILE if it can't change the default? Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
error in make: libs='-L. '; for i in crypto; do \ ( set -x; gcc \ -shared -o lib$i.so.0.9.7 \ -Wl,-soname=lib$i.so.0.9.7 \ -Wl,-Bsymbolic \ -Wl,--whole-archive lib$i.a \ -Wl,--no-whole-archive $libs -lc ) || exit 1; \ libs=$libs -l$i; \ done + gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7 -Wl,-Bsymbolic -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive -L. -lc /usr/bin/ld: warning: sparc:v9 architecture of input file `libcrypto.a(cryptlib.o)' is incompatible with sparc output /usr/bin/ld: warning: sparc:v9 architecture of input file `libcrypto.a(mem.o)' is incompatible with sparc output ... ... libcrypto.a(dso_dlfcn.o)(.text+0x5a4): In function `dlfcn_unload': : undefined reference to `dlclose' collect2: ld returned 1 exit status make[3]: *** [do_gnu-shared] Error 1 make[3]: Leaving directory `/usr/local/src/openssl-0.9.7-stable-SNAP-20021202' make[2]: *** [libcrypto.so.0.9.7] Error 2 make[2]: Leaving directory `/usr/local/src/openssl-0.9.7-stable-SNAP-20021202' make[1]: *** [shared] Error 2 make[1]: Leaving directory `/usr/local/src/openssl-0.9.7-stable-SNAP-20021202/crypto' make: *** [sub_all] Error 1 Ricardo.- Andy Polyakov wrote: linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:, all test passed (./Configure linux64-sparcv9 no-asm without no-asm). Next step is to add shared lib bits. Therefore change to: linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR), and then './Configure linux64-sparcv9 shared' and finally 'make'. Does it build? What does 'ldd apps/openssl' return? Does 'make test' pass? A. __ 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 #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Could someone verify independently that SSL_CERT_FILE doesn't rt allow reading certificates in non-default locations? I can verify, by looking at the code, that SSL_CERT_FILE should work, but only if the default cert file (/usr/local/ssl/cer.pem?) doesn't exist or is faulty. Basically, the system default seems to have precedence... Yes, it _should_ work, but it doesn't. I have tested with no file in the system default location, and the file pointed to by SSL_CERT_FILE still doesn't get read. A non-existent file shouldn't take precedence over an existing file. Even in the case of an existing default file, what would be the purpose of SSL_CERT_FILE if it can't change the default? Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
error in make: oops! Next step is to add shared lib bits. Therefore change to: linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o::dlfcn:linux-shared:-fPIC:: ^ insert -m64 here! so that it reads ...:-fPIC:-m64:.so... and then './Configure linux64-sparcv9 shared' and finally 'make'. Does it build? What does 'ldd apps/openssl' return? Does 'make test' pass? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
Andy Polyakov wrote:
Does it build?
not:
+gcc -m64 -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7
-Wl,-Bsymbolic -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive
-L. -lc
libcrypto.a(dso_dlfcn.o)(.text+0x68): In function `dlfcn_load':
: undefined reference to `dlopen'
libcrypto.a(dso_dlfcn.o)(.text+0x9c): In function `dlfcn_load':
: undefined reference to `dlerror'
libcrypto.a(dso_dlfcn.o)(.text+0x130): In function `dlfcn_load':
: undefined reference to `dlclose'
libcrypto.a(dso_dlfcn.o)(.text+0x214): In function `dlfcn_bind_var':
: undefined reference to `dlsym'
libcrypto.a(dso_dlfcn.o)(.text+0x248): In function `dlfcn_bind_var':
: undefined reference to `dlerror'
libcrypto.a(dso_dlfcn.o)(.text+0x334): In function `dlfcn_bind_func':
: undefined reference to `dlsym'
libcrypto.a(dso_dlfcn.o)(.text+0x368): In function `dlfcn_bind_func':
: undefined reference to `dlerror'
libcrypto.a(dso_dlfcn.o)(.text+0x5a4): In function `dlfcn_unload':
: undefined reference to `dlclose'
...
...
gcc -o openssl -DMONOLITH -I.. -I../include
-DOPENSSL_SYSNAME_ULTRASPARC -fPIC -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -m64 -mcpu=ultrasparc
-DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DMD5_ASM openssl.o
verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o
errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o
x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o
s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
pkcs12.o pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o -L.. -lssl
-L.. -lcrypto ; \
fi
../libcrypto.so: undefined reference to `dlerror'
../libcrypto.so: undefined reference to `dlclose'
../libcrypto.so: undefined reference to `dlopen'
../libcrypto.so: undefined reference to `dlsym'
collect2: ld returned 1 exit status
make[1]: *** [openssl] Error 1
make[1]: Leaving directory
`/usr/local/src/openssl-0.9.7-stable-SNAP-20021202/apps'
make: *** [sub_all] Error 1
adding -ldl before last -m64 flag, build!
What does 'ldd apps/openssl' return?
# ldd apps/openssl
libssl.so.0.9.7 = not found
libcrypto.so.0.9.7 = not found
libc.so.6 = /lib64/libc.so.6 (0xf811c000)
/lib64/ld-linux.so.2 = /lib64/ld-linux.so.2 (0xf800)
# LD_LIBRARY_PATH=./ ldd apps/openssl
libssl.so.0.9.7 = ./libssl.so.0.9.7 (0xf811c000)
libcrypto.so.0.9.7 = ./libcrypto.so.0.9.7 (0xf8258000)
libc.so.6 = /lib64/libc.so.6 (0xf84b8000)
libdl.so.2 = /lib64/libdl.so.2 (0xf871c000)
/lib64/ld-linux.so.2 = /lib64/ld-linux.so.2 (0xf800)
Does 'make test' pass?
yes!, thanks for all
related info:
looking inside openssl-0.9.6b source rpm from Aurora (port of RedHat 7.3
to sparc), it has this patch (I was not tested linux64-sparcv9, but
other are distributed with Aurora):.
--- openssl-engine-0.9.6b/Configure.jj Tue Apr 23 12:33:04 2002
+++ openssl-engine-0.9.6b/Configure Tue Apr 23 12:46:16 2002
@@ -172,16 +172,14 @@ my %table=(
debug-solaris-sparcv9-cc,cc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG
-DBN_CTX_DEBUG -DCRYPTO_MDEBUG_ALL -xtarget=ultra -xarch=v8plus -g -O
-xstrconst -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC::-D_REENTRANT:-lsocket
-lnsl -ldl:BN_LLONG RC4_CHAR RC4_CHUNK_LL DES_PTR DES_RISC1 DES_UNROLL
BF_PTR:asm/sparcv8plus.o:::asm/md5-sparcv8plus.o::dlfcn:solaris-shared:-KPIC:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
SPARC Linux setups
-linux-sparcv7,gcc:-DB_ENDIAN -DTERMIO $ENV{RPM_OPT_FLAGS}
-Wall::-D_REENTRANT::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR:::linux-shared:-fPIC,
+linux-sparcv7,gcc:-DB_ENDIAN -DTERMIO $ENV{RPM_OPT_FLAGS}
-Wall::-D_REENTRANT:-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR::dlfcn:linux-shared:-fPIC:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
# Ray Miller [EMAIL PROTECTED] has patiently
# assisted with debugging of following two configs.
-linux-sparcv8,gcc:-DB_ENDIAN -DTERMIO -Wall
-DBN_DIV2W::-D_REENTRANT::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR:asm/sparcv8.o::linux-shared:-fPIC,
+linux-sparcv8,gcc:-DB_ENDIAN -DTERMIO $ENV{RPM_OPT_FLAGS} -Wall
-DBN_DIV2W::-D_REENTRANT:-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR:asm/sparcv8.o:dlfcn:linux-shared:-fPIC:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
# it's a real mess with -mcpu=ultrasparc option under Linux, but
# -Wa,-Av8plus should do the trick no matter what.
-linux-sparcv9,gcc:-DB_ENDIAN -DTERMIO -Wall -DULTRASPARC
-DBN_DIV2W::-D_REENTRANT::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR:asm/sparcv8plus.o:asm/md5-sparcv8plus.o:dlfcnlinux-shared:-fPIC:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
-# !!!Folowing can't be even tested yet!!!
-#We have to wait till 64-bit glibc for SPARC is operational!!!
-#linux64-sparcv9,sparc64-linux-gcc:-m64 -DB_ENDIAN -DTERMIO -Wall
-DULTRASPARC -DBN_DIV2W::-D_REENTRANT::BN_LLONG RC4_CHAR RC4_CHUNK
DES_UNROLL
Re: [openssl.org #201] OpenSSL 0.9.6e failing make test
On December 3, 2002 03:09 am, Lutz Jaenicke via RT wrote: On Mon, Dec 02, 2002 at 08:35:43PM +0100, [EMAIL PROTECTED] via RT wrote: Hmm. According to http://www.perldoc.com/perl5.6/pod/perlpod.html there only exist =head1 and =head2, so the complaint is correct :-) Geoff??? Hmm, bollocks. I can't confess to having studied the perlpod documentation on this - I merely wondered if I could get away with a [snip] you are the doc-god, what do you think we should do? I'm obviously the first to want a third level of header nesting, but I may not be the last ... With respect to the link I cited above, the =head directive only supports level 1 and level 2. If we intend to maintain compatibility with standard perlpod, and I think we do :-), there is no level 3 and that is it. Thus the manual page needs restructuring. Well I decided to do a little fishing ... this is apparently not a limitation of groff/man (which is what counts, after all) but a limitation of the pod2man implementation in version 5.6 of perl. Version 5.8 gives *four* levels of nesting; http://www.perldoc.com/perl5.8.0/pod/perlpod.html I can go and cripple the engine.pod documentation if absolutely necessary, but it simply seems a somewhat shortsighted solution (even if alliterative :-). IIRC there was some discussion a while back about bundled implementations of pod2man or something like that? Could we simply use a 5.8-compatible bundled implementation if the host system's version is too old? Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ The bastards have beaten off rationalism for now, but haven't eliminated our capacity for reason - to do that they'd have to make us forget how to both think and fear at the same time. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: Changed release dates, and a plea for testers
On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker wrote: Please try the 0.9.6 snapshots *today* or during the day tomorrow. Quick bug fixes will be honored, others will only be applied to the 0.9.7 branch. Any progress on getting rsync working again on dev.openssl.org? I really prefer using my local copy of CVS over pulling snapshots every time. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
Does it build?
+gcc -m64 -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7
-Wl,-Bsymbolic -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive
-L. -lc
libcrypto.a(dso_dlfcn.o)(.text+0x68): In function `dlfcn_load':
: undefined reference to `dlopen'
Double oops:-) Of course there should have been -ldl in appropriate
place in the config-line! See any other Linux line in inject -ldl in the
same spot into the linux64-sparcv9 line.
adding -ldl before last -m64 flag, build!
Great!
What does 'ldd apps/openssl' return?
# LD_LIBRARY_PATH=./ ldd apps/openssl
libssl.so.0.9.7 = ./libssl.so.0.9.7 (0xf811c000)
libcrypto.so.0.9.7 = ./libcrypto.so.0.9.7 (0xf8258000)
libc.so.6 = /lib64/libc.so.6 (0xf84b8000)
libdl.so.2 = /lib64/libdl.so.2 (0xf871c000)
/lib64/ld-linux.so.2 = /lib64/ld-linux.so.2 (0xf800)
Great! Well, as long as we disregard the long-standing OpenSSL
deficiency such as lack of support for multiple-ABI platforms. I mean
one ultimately wants same headers working with either supported ABI and
linker to automatically locate appropriate libraries depending on
-m32/64 option.
Does 'make test' pass?
yes!, thanks for all
Great!
related info:
looking inside openssl-0.9.6b source rpm from Aurora (port of RedHat 7.3
to sparc), it has this patch (I was not tested linux64-sparcv9, but
other are distributed with Aurora):
...
+linux64-sparcv9,gcc:-m64 -DB_ENDIAN -DTERMIO $ENV{RPM_OPT_FLAGS}
-Wall -DULTRASPARC -DBN_DIV2W::-D_REENTRANT:-ldl:BN_LLONG RC4_CHAR
RC4_CHUNK DES_UNROLL
I find it hard to believe that it was ever tested/worked. BN_LLONG and
BN_DIV2W is impossible combination on LP64.
A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #201] OpenSSL 0.9.6e failing make test
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 18:08:25 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt I can go and cripple the engine.pod documentation if absolutely necessary, rt but it simply seems a somewhat shortsighted solution (even if rt alliterative :-). IIRC there was some discussion a while back about rt bundled implementations of pod2man or something like that? Could we rt simply use a 5.8-compatible bundled implementation if the host system's rt version is too old? I've no problem with bundling a newer version. After all, we have something bundled in right now! -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: status of support sparc64 on linux
In message [EMAIL PROTECTED] on Wed, 04 Dec 2002 18:28:11 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro Great! Well, as long as we disregard the long-standing OpenSSL appro deficiency such as lack of support for multiple-ABI platforms. I mean appro one ultimately wants same headers working with either supported ABI and appro linker to automatically locate appropriate libraries depending on appro -m32/64 option. If someone tells me how to do such a thing, I can think of hacking 0.9.8 to do that. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #201] OpenSSL 0.9.6e failing make test
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 18:08:25 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt I can go and cripple the engine.pod documentation if absolutely necessary, rt but it simply seems a somewhat shortsighted solution (even if rt alliterative :-). IIRC there was some discussion a while back about rt bundled implementations of pod2man or something like that? Could we rt simply use a 5.8-compatible bundled implementation if the host system's rt version is too old? I've no problem with bundling a newer version. After all, we have something bundled in right now! -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
I asked Eric Rescorla, and he agreed the section of the TLS RFC was definitely unclear, but he wasn't totally sure which way it should go as far as stripping any leading 0s before using the shared secret to generate keys. It basically depends on what various implementations have decided to do. -J On Wed, 4 Dec 2002, Richard Levitte via RT wrote: I haven't heard any news about this. I also mailed ietf-tls asking about this, but had no response there either. That means there will most probably be no fix in 0.9.6h. 0.9.7 still has a week... I think I'll change the miestone for this fix. [[EMAIL PROTECTED] - Thu Nov 14 19:05:29 2002]: In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 20:24:30 +0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said: rt The existing code could be fixed to handle other cases, for example by rt dumping that BIO_gets() replacing with a BIO_read() loop and converting rt the buffer in place. Alternatively a filter BIO that can handle EOL rt conversion could be written. Hmm, BIO_f_linebuffer() seems to be something to build from. Right now, it's an output-only buffering filter, but can easily be made an input filter as well. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 20:24:30 +0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said: rt The existing code could be fixed to handle other cases, for example by rt dumping that BIO_gets() replacing with a BIO_read() loop and converting rt the buffer in place. Alternatively a filter BIO that can handle EOL rt conversion could be written. Hmm, BIO_f_linebuffer() seems to be something to build from. Right now, it's an output-only buffering filter, but can easily be made an input filter as well. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #378] building without md5
MD5 is one of those algorithms that's used so much it isn't easy to disable. However, you only had problems in two files with it, we're apparently doing fine. I'll investigate and get back to you. [[EMAIL PROTECTED] - Wed Dec 4 11:09:43 2002]: System and version: --- OpenSSL 0.9.7 BETA 4 Host: Debian woody (3.0) Type: - Building , Configuration error Description: when configuring openssl with: './config -no-md5' make depend fails because it includes 'md5.h' in 'test/hmactest.c' and 'ssl/s3_srvr.c' Reproduction: - $ ./config -no-md5 $ make depend Failure message: ../util/domd .. -MD gcc -- -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MD5 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_TLS1 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=k6 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -I.. -I../include -DOPENSSL_NO_MD5 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_TLS1 -- bntest.c ectest.c ideatest.c md2test.c md4test.c md5test.c hmactest.c rc2test.c rc4test.c rc5test.c destest.c shatest.c sha1test.c mdc2test.c rmdtest.c randtest.c dhtest.c enginetest.c casttest.c bftest.c ssltest.c dsatest.c exptest.c rsa_test.c evp_test.c In file included from hmactest.c:71: ../include/openssl/md5.h:67: #error MD5 is disabled. make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7- beta4/test' making dependencies tools... make[1]: Entering directory `/home/chris/src/diff/openssl-0.9.7- beta4/tools' make[1]: Nothing to be done for `depend'. make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7- beta4/tools' $ ./config -no-md5 -no-hmac $ make depend $ make Failure message: In file included from s3_srvr.c:125: ../include/openssl/md5.h:67: #error MD5 is disabled. make[1]: *** [s3_srvr.o] Error 1 make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7- beta4/ssl' make: *** [sub_all] Error 1 Regards Christian -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #379] ssltest.c build breaks in 0.9.7-stable on Solaris/x86 with GCC
Fix committed. Thanks for the report. This ticket is now resolved. [guest - Wed Dec 4 11:18:25 2002]: ssltest.c doesn't currently build (from 0.9.7-stable branch) with GCC 2.95.x on Solaris/x86 platforms; failures are like: gcc -I.. -I../include -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -O3 -fomit-frame-pointer -m486 -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c ssltest.c In file included from ../include/openssl/bio.h:65, from ssltest.c:128: /usr/local/lib/gcc-lib/i386-pc-solaris2.6/2.95.3/include/stdarg.h:170: conflicting types for `va_list' /usr/include/stdio.h:90: previous declaration of `va_list' *** Error code 1 The #define _XOPEN_SOURCE 600 is the culprit, it seems, which is for Linux systems apparently. The glibc unistd.h I have defines gethostname on this conditional: #if defined __USE_BSD || defined __USE_XOPEN2K so the attached patch seems like a reasonable fix. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #382] building without rc4 fails
Change committed. Thanks for the report. This ticket is now resolved. [[EMAIL PROTECTED] - Wed Dec 4 12:25:20 2002]: System and version: --- OpenSSL 0.9.7 BETA 4 Host: Debian woody (3.0) Type: - Building , Configuration error Description: when configuring openssl with: './config -no-rc4' make fails because it includes 'rc4.h' in 'crypto/engine/eng_openssl.c' Reproduction: - $ rm -rf openssl-0.9.7-beta4 $ tar zxf openssl-0.9.7-beta4.tar.gz $ cd openssl-0.9.7-beta4 $ ./config -no-rc4 $ make depend $ make Failure message: make[2]: Entering directory `/home/chris/src/diff/openssl-0.9.7- beta4/crypto/engine' gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_RC4 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=k6 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c -o eng_openssl.o eng_openssl.c In file included from eng_openssl.c:184: ../../include/openssl/rc4.h:63: #error RC4 is disabled. make[2]: *** [eng_openssl.o] Error 1 make[2]: Leaving directory `/home/chris/src/diff/openssl-0.9.7- beta4/crypto/engine' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/chris/src/diff/openssl-0.9.7- beta4/crypto' make: *** [sub_all] Error 1 Regards Christian -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #374] [PATCH] Port to LynxOS and further support for VxWorks
I've applied the VxWorks parts. The LynxOS part is too big at this point. I will resolve this ticket, and would like to ask you to concentrate the LynxOS development on 0.9.7 or 0.9.8. Thanks for your effort. [[EMAIL PROTECTED] - Tue Dec 3 13:54:54 2002]: Hello! This patch set includes a port of OpenSSL to LynxOS, and some further work on the VxWorks port. The libraries and test programs now build and run on both platforms; the patches were made against the 0.9.6g version of OpenSSL. I have submitted a TSA notification as outlined in the README file and the Bureau of Industry and Security web site. I'd greatly appreciate it if you would include these changes in the future releases of OpenSSL. Thanks, Matt Titus [EMAIL PROTECTED] -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #381] [PATCH] for openssl-0.9.7-beta4 to fix some bugs in the chil engine code (hw_ncipher.c)
[[EMAIL PROTECTED] - Wed Dec 4 12:08:18 2002]:
Whilst conducting some testing with OpenSSL 0.9.7beta4 and the nCipher
chil plugin, I observed the following issues:
1. Lack of threadsafety if app fails to support new OpenSSL dynamic
locks
At the moment hw_ncipher.c uses the new OpenSSL dynamic lock code
inorder
to implement the hwcrhk locking upcalls. However if the OpenSSL
application
fails to implement the dynamic upcalls, i.e.
CRYPTO_get_dynlock_create_callback() returns NULL, then the hwcrhk
engine
code becomes non threadsafe.
Hmm, that's a good point. However, your solution is not the way to go.
If you take a look at 0.9.8-dev, you'll see that the engines
increasingly become some kind of external module. Therefore, it's not a
good idea to fool the programmers into thinking they can rely on OpenSSL
having the proper static lock for the available engines.
However, if we can do a good enough assertion (which will not abort(),
just make the engine not load), I can see us doing that. Care to help
in that direction? It'll probably involve using
CRYPTO_get_locking_callback() to see if the application provided any
threading support. If it does that, but hasn't provided any support for
dynamic locks, it's bye-bye engine... Sounds reasonable enough?
2. Missing emsg in call to p_hwcrhk_ModExpCRT() in hw_ncipher.c
Applied and committed. Thanks.
3. hwcrhk_log_message() in hw_ncipher.c
This fails to write a newline character to the logstream after each
log message. So for instance setting debug in s_client produces:
I applied and committed a patch that uses BIO_printf().
4. hwcrhk_insert_card() in hw_ncipher.c
[...]
int UI_dup_info_string(UI *ui, const char *text)
{
char *text_copy=NULL;
if (text)
{
text_copy=BUF_strdup(text);
if (text_copy == NULL)
{
UIerr(UI_F_UI_DUP_INFO_STRING,ERR_R_MALLOC_FAILURE);
return -1;
}
}
return general_allocate_string(ui, text_copy, 1, UIT_INFO, 0, NULL,
0, 0, NULL);
}
Actually, the error was deep down in general_allocate_prompt(), which
should have checked type. Patched and committed...
I hope that this mail is helpful,
Very much so. Thanks!
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #381] [PATCH] for openssl-0.9.7-beta4 to fix some bugs in the chil engine code (hw_ncipher.c)
OK, I've now make a change that should take care of the assertion as I imagined it. Could you please grab the next snapshot and test it? I'm resolving this ticket, so please, if you find errors, generate a new bug report. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
I've changed the behavior so that it will FIRST try to get the file pointed at with the environment variable. If the environment variable wasn't set or loading the file failed, then the system default file will be loaded. If that fails, an error is generated. by_dir.c looks a little weird too, but probably works... This ticket is now resolved. [[EMAIL PROTECTED] - Wed Dec 4 16:29:23 2002]: On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Could someone verify independently that SSL_CERT_FILE doesn't rt allow reading certificates in non-default locations? I can verify, by looking at the code, that SSL_CERT_FILE should work, but only if the default cert file (/usr/local/ssl/cer.pem?) doesn't exist or is faulty. Basically, the system default seems to have precedence... Yes, it _should_ work, but it doesn't. I have tested with no file in the system default location, and the file pointed to by SSL_CERT_FILE still doesn't get read. A non-existent file shouldn't take precedence over an existing file. Even in the case of an existing default file, what would be the purpose of SSL_CERT_FILE if it can't change the default? Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #380] VC-WIN32 build issue
OK, I've made that change. This ticket is now resolved. [[EMAIL PROTECTED] - Wed Dec 4 12:07:51 2002]: testing with openssl-0.9.7-stable-SNAP-20021203 ... in util/pl/VC-32.pl there is a line $lib_cflag= -D_WINDLL -D_DLL; which causes problems if the /MT option in $cflags is changed to /MT (solution is to remove the -D_DLL in this senario). since according to the help for VC7, /MD also defines _DLL the -D_DLL is unnecssary. (I think this is also the case in VC4-VC6) therefore I suggest just removing the -D_DLL permantly, so if somebody changes the /MD to /MT they dont have to spend ages working out why it doesnt link. Louis Solomon www.SteelBytes.com -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
I've changed the behavior so that it will FIRST try to get the file pointed at with the environment variable. If the environment variable wasn't set or loading the file failed, then the system default file will be loaded. If that fails, an error is generated. I don't think silently using something other than specified is a good idea. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
I've changed the behavior so that it will FIRST try to get the file pointed at with the environment variable. If the environment variable wasn't set or loading the file failed, then the system default file will be loaded. If that fails, an error is generated. I don't think silently using something other than specified is a good idea. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and0.9.6
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 21:08:43 -0500 (EST), Rich Salz [EMAIL PROTECTED] said: rsalz I've changed the behavior so that it will FIRST try to get the file rsalz pointed at with the environment variable. If the environment variable rsalz wasn't set or loading the file failed, then the system default file will rsalz be loaded. If that fails, an error is generated. rsalz rsalz I don't think silently using something other than specified is a good rsalz idea. Hmm? Please note that this is only for the case where the application author has explicitely asked for a default certificate, through something like 'X509_LOOKUP_load_file(lookup,NULL,X509_FILETYPE_DEFAULT)'. Note the last argument. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #380] VC-WIN32 build issue
thnx Louis Solomon www.SteelBytes.com - Original Message - From: Richard Levitte via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 12:37 PM Subject: [openssl.org #380] VC-WIN32 build issue OK, I've made that change. This ticket is now resolved. [[EMAIL PROTECTED] - Wed Dec 4 12:07:51 2002]: testing with openssl-0.9.7-stable-SNAP-20021203 ... in util/pl/VC-32.pl there is a line $lib_cflag= -D_WINDLL -D_DLL; which causes problems if the /MT option in $cflags is changed to /MT (solution is to remove the -D_DLL in this senario). since according to the help for VC7, /MD also defines _DLL the -D_DLL is unnecssary. (I think this is also the case in VC4-VC6) therefore I suggest just removing the -D_DLL permantly, so if somebody changes the /MD to /MT they dont have to spend ages working out why it doesnt link. Louis Solomon www.SteelBytes.com -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] supporting the x86_64 architecture
On Wed, Nov 27, 2002 at 12:53:31AM +0100, Andy Polyakov wrote: to facilitate building openssl on the x86_64 platform I suggest to apply the attached patch. +linux-x86_64, gcc:-DL_ENDIAN -DNO_ASM: Linux/x86_64 suports two ABIs. As far as I understand it's perfectly possible to compile gcc so that it supports both. Which one will be default? To ensure that intended ABI is chosen I'd recommend to add -m64 to command line. The 64-bit environment is the default. The compiler seems to know... we don't use -m64 explicitely. Why don't you use -O? I had no problem with -O3 and gcc-3.2... We use -O2 but I hand it over on the command line, because compilers are unsteady guys I have heard bad things about -O3, like making binaries slower and larger. -O2 is what has been tested most, it seems. As for NO_ASM. Do you have real x86_64 hardware? I have been working on BN assembler aided implementation that would need some benchmarking. It should give around 3x speed-up... If you have real hardware is it possible to get an account? I'll see how I can get you in contact with someone, Peter -- Gravity is an unforgiving motherfucker. msg14175/pgp0.pgp Description: PGP signature
Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6
author has explicitely asked for a default certificate, through something like 'X509_LOOKUP_load_file(lookup,NULL,X509_FILETYPE_DEFAULT)'. Note the last argument. Sure, but if they told you a filename and it contains garbage than I think it's an error. If they told you a filename and it doesn't exist, then I htink that's an error. If they don't give you a filename, then you're on your own to find a default. My view. Worth what you paid for it. Don't know if this should go to rt, openssl-dev, or both... /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
