RAND_Status lock
I'm using a DLL that encrypt/Decrypt files, when I execute the DLL using a foreground application works, but when I execute the DLL running under a background program It is locking calling RAND_Status function. This is under WinNT environment, I use the DLL in services and ATL COM Servers and always I got this lock. I don't know much about this issue so I appreciate any help. David Pineda __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #96] bug in config script (gcc 3.1)
In message [EMAIL PROTECTED] on Thu, 13 Jun 2002 14:52:11 -0700, Allen Hopkins [EMAIL PROTECTED] said: allenh I'm afraid this was not a fix. Have you tried it with gcc-3.1? allenh I encountered this problem with the 0.9.6d snapshot. I tried it just now, GCCVER becamse 31, and my output was -- gcc (GCC) 3.1.1 20020606 (Debian prerelease) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- -- 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 #85] 0.9.7 prototype constification problems
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. On the other hand, I can't pass the address of const unsigned char *p to the old-style function. Neither situation is desirable... but it looks like you might have to just use two different functions with two different APIs, unfortunately. I don't know another way out. Have fun, Avery __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #96] bug in config script (gcc 3.1)
In message [EMAIL PROTECTED] on Thu, 13 Jun 2002 14:52:11 -0700, Allen Hopkins [EMAIL PROTECTED] said: allenh I'm afraid this was not a fix. Have you tried it with gcc-3.1? allenh I encountered this problem with the 0.9.6d snapshot. I tried it just now, GCCVER becamse 31, and my output was -- gcc (GCC) 3.1.1 20020606 (Debian prerelease) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- -- 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 #65] Ticket Resolved
On Thu, Jun 13, 2002 at 06:05:34PM +0200, Kambez Sadeq via RT wrote:
Any idea why web browsers such as MSIE and Opera work okay with the server?
I'm guessing that these browsers ignore invalid records.
No, the server (actually a broken proxy to a real server apparently)
does not send invalid records under certain conditions. I used
s_client to send the following lines and it worked:
GET / HTTP/1.1
Host: ebmx.extra.daimlerchrysler.com
But when faced with inappropriate Host lines, the server behaves
erratically. I can connect to it using Netscape, but if I tunnel
through localhost (so that the real target host is not named in
Host) I get plaintext error messages; see the following partial
connection transcript (the lines are an SSL encrypted HTTP
request [so you can't read anything], the lines are the server's
response, which is sent in cleartext).
000114 17 03 00 01 26 42 fc 09 da 38 85 b8 60 98 ea b1 B...8..`...
000124 be 49 13 66 71 42 ab 11 b9 25 df 47 f1 d9 69 7c .I.fqB...%.G..i|
000134 a6 f2 72 a0 2e e2 7c 0a 2b 91 a8 e5 6b 77 ef 95 ..r...|.+...kw..
000144 fe 64 e2 e3 db a6 12 4b 8c 96 ed c4 f9 16 2b 05 .d.K..+.
000154 9a 4d d6 59 2a f9 cf 68 7d a6 04 ba 87 bd 83 f4 .M.Y*..h}...
000164 24 16 e9 71 f0 b9 b6 b8 16 e9 16 24 5c c5 a6 8b $..q...$\...
000174 81 84 14 77 28 4e 4b eb a4 94 13 52 76 c1 5b 39 ...w(NKRv.[9
000184 8e bc 96 6f fa 1c ca 4e ee ec 69 a6 85 7c 7d 6e ...o...N..i..|}n
000194 73 a5 54 8a de 9c 82 2d 9e 25 82 4a 46 3e 06 79 s.T-.%.JF.y
0001a4 0c cc 8b 1f c0 9f 5c 95 40 e7 51 b6 d2 38 75 b7 ..\.@.Q..8u.
0001b4 68 91 60 f1 f8 1a c3 d1 97 13 c6 63 28 37 93 65 h.`c(7.e
0001c4 aa b4 f2 d1 49 6b 5f cf 66 e1 40 cc 66 01 b1 44 Ik_.f.@.f..D
0001d4 4e 24 2b 04 23 26 2e bf a1 ff 57 6c 2a 52 01 68 N$+.#Wl*R.h
0001e4 3e 99 b7 1b 5e 7b c3 6d 72 6a ce 3e 89 98 9f 38 ...^{.mrj8
0001f4 17 6d 5a dd 3a f7 52 cd 9b cc 5c a4 a4 83 02 a9 .mZ.:.R...\.
000204 50 36 32 b2 44 11 f9 45 b7 c7 d8 5f 9d 6c 24 e6 P62.D..E..._.l$.
000214 22 58 9a 01 58 ba 2b a8 f7 d0 ca 78 a8 2b cc d4 X..X.+x.+..
000224 29 75 fd 24 38 1d c6 30 df b5 f0 48 5d cd d2 01 )u.$8..0...H]...
000234 51 21 cf d8 99 ac 6b 3e 1b 66 90 Q!k.f.
000c63 48 54 54 50 2f 31 2e 30 20 35 30 30 20 45 72 72 HTTP/1.0 500 Err
000c73 6f 72 20 66 72 6f 6d 20 70 72 6f 78 79 0d 0a 4d or from proxy..M
000c83 69 6d 65 2d 76 65 72 73 69 6f 6e 3a 20 31 2e 30 ime-version: 1.0
000c93 0d 0a 50 72 6f 78 79 2d 61 67 65 6e 74 3a 20 4e ..Proxy-agent: N
000ca3 65 74 73 63 61 70 65 2d 50 72 6f 78 79 2f 33 2e etscape-Proxy/3.
000cb3 35 33 0d 0a 43 6f 6e 74 65 6e 74 2d 74 79 70 65 53..Content-type
000cc3 3a 20 74 65 78 74 2f 68 74 6d 6c 0d 0a 0d 0a 3c : text/html
000cd3 48 54 4d 4c 3e 0a 3c 48 45 41 44 3e 3c 54 49 54 HTML.HEADTIT
000ce3 4c 45 3e 45 72 72 6f 72 3c 2f 54 49 54 4c 45 3e LEError/TITLE
000cf3 3c 2f 48 45 41 44 3e 0a 3c 42 4f 44 59 3e 0a 3c /HEAD.BODY.
000d03 48 31 3e 45 72 72 6f 72 3c 2f 48 31 3e 0a 3c 42 H1Error/H1.B
000d13 4c 4f 43 4b 51 55 4f 54 45 3e 3c 42 3e 0a 3c 48 LOCKQUOTEB.H
000d23 52 20 53 49 5a 45 3d 34 3e 3c 50 3e 0a 54 68 65 R SIZE=4P.The
000d33 20 72 65 71 75 65 73 74 65 64 20 69 74 65 6d 20 requested item
000d43 63 6f 75 6c 64 20 6e 6f 74 20 62 65 20 6c 6f 61 could not be loa
000d53 64 65 64 20 62 79 20 74 68 65 20 70 72 6f 78 79 ded by the proxy
000d63 2e 3c 50 3e 0a 54 68 69 73 20 4c 6f 63 61 74 69 .P.This Locati
000d73 6f 6e 20 28 55 52 4c 29 20 69 73 20 6e 6f 74 20 on (URL) is not
000d83 72 65 63 6f 67 6e 69 7a 65 64 3a 0a 20 20 66 69 recognized:. fi
000d93 6c 65 3a 2f 0a 0a 43 68 65 63 6b 20 74 68 65 20 le:/..Check the
000da3 4c 6f 63 61 74 69 6f 6e 20 61 6e 64 20 74 72 79 Location and try
000db3 20 61 67 61 69 6e 2e 3c 50 3e 0a 0a 3c 48 52 20 again.P..HR
000dc3 53 49 5a 45 3d 34 3e 0a 3c 2f 42 3e 3c 2f 42 4c SIZE=4./B/BL
000dd3 4f 43 4b 51 55 4f 54 45 3e 0a 0a 3c 50 3e 0a 3c OCKQUOTE..P.
000de3 41 44 44 52 45 53 53 3e 50 72 6f 78 79 20 73 65 ADDRESSProxy se
000df3 72 76 65 72 20 61 74 20 6f 64 73 70 6e 70 72 34 rver at odspnpr4
000e03 2d 68 6d 65 30 2e 65 78 74 72 61 2e 64 61 69 6d -hme0.extra.daim
000e13 6c 65 72 63 68 72 79 73 6c 65 72 2e 63 6f 6d 20 lerchrysler.com
000e23 6f 6e 20 70 6f 72 74 20 34 34 33 3c 2f 41 44 44 on port 443/ADD
000e33 52 45 53 53 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 RESS./BODY/H
000e43 54 4d 4c 3e 0a TML.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL
Re: [openssl.org #85] 0.9.7 prototype constification problems
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. On the other hand, I can't pass the address of const unsigned char *p to the old-style function. Neither situation is desirable... but it looks like you might have to just use two different functions with two different APIs, unfortunately. I don't know another way out. Have fun, Avery __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: getpid()
On Thu, Jun 13, 2002 at 05:20:42PM +0100, Ben Laurie wrote: However, the number of calls is astonishing - and must be significantly expensive, too. Memory debugging *is* expensive. It is only enabled by default in debug configurations, where (starting with 0.9.7) it can be disabled by setting environment variable OPENSSL_DEBUG_MEMORY to off. (In non-debug configurations, it can be enabled by setting OPENSSL_DEBUG_MEMORY to a string other than off.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #97] About 0.9.6a(b) and des_encrypt1()
From CHANGES: *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes with des_encrypt() defined on some operating systems, like Solaris and UnixWare. [Richard Levitte] Just wanted to let you guys know, that also this symbol is in use by Solaris (7), libcrypt: # nm /usr/lib/libcrypt.a | grep des_encrypt U _des_encrypt des_encrypt.o: T _des_encrypt1 W des_encrypt1 025c T _des_encrypt U _des_encrypt1 025c W des_encrypt 01bc t des_encrypt_nolock --Jani __ 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 #97] About 0.9.6a(b) and des_encrypt1()
On Wed, 8 Aug 2001, [iso-8859-1] Götz Babin-Ebell wrote: Richard Levitte - VMS Whacker wrote: Hmm, it feels like it's really time for a rename (basically, change des to DES in all names, and thereby follow the convention used everywhere else in OpenSSL), or this becomes an impossible task. openssl_des_... ? in the sources we can have a #define des_...() openssl_des_...() If a change is going to be made, it makes sense to bring the naming in line with the rest of the code, thus DES_*** makes more sense. (IMHO, IANAL, etc :-) Cheers, Geoff __ 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 #97] About 0.9.6a(b) and des_encrypt1()
Richard Levitte - VMS Whacker wrote: From: Jani Taskinen [EMAIL PROTECTED] sniper From CHANGES: sniper sniper *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes sniper with des_encrypt() defined on some operating systems, like Solaris sniper and UnixWare. sniper [Richard Levitte] sniper sniper sniper Just wanted to let you guys know, that also sniper this symbol is in use by Solaris (7), libcrypt: sniper sniper # nm /usr/lib/libcrypt.a | grep des_encrypt sniper U _des_encrypt sniper des_encrypt.o: sniper T _des_encrypt1 sniper W des_encrypt1 sniper 025c T _des_encrypt sniper U _des_encrypt1 sniper 025c W des_encrypt sniper 01bc t des_encrypt_nolock Hmm, it feels like it's really time for a rename (basically, change des to DES in all names, and thereby follow the convention used everywhere else in OpenSSL), or this becomes an impossible task. openssl_des_... ? in the sources we can have a #define des_...() openssl_des_...() By Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #97] About 0.9.6a(b) and des_encrypt1()
From: Jani Taskinen [EMAIL PROTECTED] sniper From CHANGES: sniper sniper *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes sniper with des_encrypt() defined on some operating systems, like Solaris sniper and UnixWare. sniper [Richard Levitte] sniper sniper sniper Just wanted to let you guys know, that also sniper this symbol is in use by Solaris (7), libcrypt: sniper sniper # nm /usr/lib/libcrypt.a | grep des_encrypt sniper U _des_encrypt sniper des_encrypt.o: sniper T _des_encrypt1 sniper W des_encrypt1 sniper 025c T _des_encrypt sniper U _des_encrypt1 sniper 025c W des_encrypt sniper 01bc t des_encrypt_nolock Hmm, it feels like it's really time for a rename (basically, change des to DES in all names, and thereby follow the convention used everywhere else in OpenSSL), or this becomes an impossible task. For source compatibility, it's of course perfectly possible to provide macros so older applications don't break immediately. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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 Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #97] About 0.9.6a(b) and des_encrypt1()
[[EMAIL PROTECTED] - Fri Jun 14 12:02:20 2002]: From CHANGES: *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes with des_encrypt() defined on some operating systems, like Solaris and UnixWare. [Richard Levitte] Just wanted to let you guys know, that also this symbol is in use by Solaris (7), libcrypt: This problem has been resolved for 0.9.7... Is it worthwile to make a small adjustment for 0.9.6e (in case it will be released)? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: About the des_encrypt1() problem with Solaris..
On Thu, Jun 13, 2002 at 10:58:43PM +0300, Jani Taskinen wrote: This problem described here: http://marc.theaimsgroup.com/?l=openssl-devm=99720385817987w=2 Still exists in 0.9.6d release..when can this be expected to be fixed? As you will note, I have injected the old thread into the request tracker. Best regards, Lutz -- 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 #87] Ticket #87, #90 resolved (empty fragments for CBC)
The CBC vulnerability countermeasure that cannot be handled by some broken SSL/TLS implementations can now be disabled with the new SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option, which is also part of SSL_OP_ALL and thus will be automatically enabled in many OpenSSL applications designed to be compatible with weird implementations. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #65] 0.9.6d: SSL3_GET_RECORD:wrong version number
Status was (automatically?) changed from resolved to open by additional correspondance. The actual status is resolved. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #34] SSL through Netscape Proxy server
Not a bug in OpenSSL, should have been sent to openssl-users __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #27] Legalizing OpenSSL in France
Not an OpenSSL bug, this should be discussed elsewhere (openssl-users). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #87] openssl 0.9.6b to 0.9.6d with IE5.5 and IE6 and 3DES-CBC-SHA hangs
Dear Mr. Moeller, I totally agree that it is an IE bug but unfortunately we have to live with IE(!) and so by Microsoft doctrine (!) it's the other programs that interact with IE that have bugs ... Seriously, I wish to thank you and the other people in the ssl development team for your effort and resolve to fix this annoyance, Thanks a lot, E.I.Sarmas - Original Message - From: Bodo Moeller via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: ÐÝìðôç, 13 Éïõíßïõ 2002 12:18 ìì Subject: [openssl.org #87] openssl 0.9.6b to 0.9.6d with IE5.5 and IE6 and 3DES-CBC-SHA hangs [[EMAIL PROTECTED] - Fri Jun 7 14:22:15 2002]: even though Netscape still works, this should be considered a bug since IE is now broken when in the past it worked fine It is a bug in IE, not in OpenSSL. Note that the problem is avoided when using RC4 ciphersuites, and these are typically preferred by most clients anyway. However OpenSSL clients prefer 3DES ciphersuites by default, so interoperability problems of OpenSSL clients with broken servers must be expected. Future versions of OpenSSL will be modified so that the CBC security workaround that caused these problems with some broken SSL/TLS implementations can be disabled. We have to decide whether to give higher priority to security (enable the workaround by default and let applications that don't need it, such is Apache with mod_ssl or Apache-SSL, disable it) or to interoperability (disable the workaround by default and rely on applications to enable it when it is needed). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Linking the libraries.
Hello, I'm new to openssl (sort of) and I have a problem/question. I am trying to compile fetchmail-5.9.12 with ssl support but something strange is happening. Compilation goes ok but when it's all done I do a 'ldd ./fetchmail' and it turns out the libraries are dynamically linked to the fetchmail binary but with the full filename. The output of ldd says: libcrypto.so.0.9.6 = /usr/local/ssl/lib/libcrypto.so.0.9.6 I would expect something like this: libcrypto.so.0 = /usr/local/ssl/lib/libcrypto.0 It's the same with libssl (ofcourse). I would expect the linker to use the symlinks pointing to the 'real' files but somehow it doesn't. Yes, the symlinks are there, 'make install' created them. I've build the libraries with './config shared threads; make'. Is there a solution for this? -- Best regards, Henri mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #97] About 0.9.6a(b) and des_encrypt1()
On Fri, 14 Jun 2002, Lutz Jaenicke via RT wrote: [[EMAIL PROTECTED] - Fri Jun 14 12:02:20 2002]: From CHANGES: *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes with des_encrypt() defined on some operating systems, like Solaris and UnixWare. [Richard Levitte] Just wanted to let you guys know, that also this symbol is in use by Solaris (7), libcrypt: This problem has been resolved for 0.9.7... Great. Is it worthwile to make a small adjustment for 0.9.6e (in case it will be released)? If 0.9.7 is due to be released soon (?) then I don't think that's necessary..but of course if there will be another release of 0.9.6 then it would be nice to have this in it. --Jani __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #96] bug in config script (gcc 3.1)
Richard- Strange. I guess it's time to compare what we're looking at. I'm running on a Sun Ultra-60 w/ SunOS 5.8. I downloaded openssl-0.9.6d.tar.gz from http://www.openssl.org/source/. I then ran the following command: ./config --prefix=/usr/local/openssl-0.9.6d \ --openssldir=/usr/local/openssl-0.9.6d The output from that was: Operating system: sun4u-whatever-solaris2 ./config: test: unknown operator (GCC) The config script is dated Mar 15 08:47 (which I think is 15:47 GMT, since I'm in California and we're on Daylight Savings Time). Its size is 17352 bytes. The line that errors out for me is line 613: if [ $OUT = solaris-sparcv9-gcc -a $GCCVER -lt 28 ] I put the following in front of it to see the value of GCCVER: echo GCCVER = \$GCCVER\; exit and got this output: Operating system: sun4u-whatever-solaris2 GCCVER = gcc (GCC) 31 With the value of GCCVER having embedded whitespace, you can see why test would give up on it. I hope this helps. Let me know if you need anything else from me. -Allen Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Thu, 13 Jun 2002 14:52:11 -0700, Allen Hopkins [EMAIL PROTECTED] said: allenh I'm afraid this was not a fix. Have you tried it with gcc-3.1? allenh I encountered this problem with the 0.9.6d snapshot. I tried it just now, GCCVER becamse 31, and my output was -- gcc (GCC) 3.1.1 20020606 (Debian prerelease) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- -- 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]
problem config
Hi openssl-dev, ~~/src/openssl-0.9.6d.src root@galilee gcc --version gcc (GCC) 3.1 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. vi config 383 # figure out if gcc is available and if so we use it otherwise 384 # we fallback to whatever cc does on the system 385 GCCVER=`(gcc --version) 2/dev/null` 386 if [ $GCCVER != ]; then 387CC=gcc 388# then strip off whatever prefix Cygnus prepends the number with... 389GCCVER=`echo $GCCVER | sed 's/^[a-z]*\-//'` 390GCCVER=`echo $GCCVER | sed 's/(GCC)//'` 391GCCVER=`echo $GCCVER | sed 's/^[a-z]*//'` 392# peak single digit before and after first dot, e.g. 2.95.1 gives 29 393GCCVER=`echo $GCCVER | sed 's/\([0-9]\)\.\([0-9]\).*/\1\2/'` 394 else 395CC=cc 396 fi ... Add line 390, 391 -- Regards CETELEM - Equipe système Unix / Xnet. [2-2329] Eric Vanborren 20 av. Georges Pompidou - 92595 Levallois Perret - FRANCE Tél: +33 1.46.39.2329 - e-mail: [EMAIL PROTECTED] May The OpenSource be with you ! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #96] bug in config script (gcc 3.1)
Richard- Strange. I guess it's time to compare what we're looking at. I'm running on a Sun Ultra-60 w/ SunOS 5.8. I downloaded openssl-0.9.6d.tar.gz from http://www.openssl.org/source/. I then ran the following command: ./config --prefix=/usr/local/openssl-0.9.6d \ --openssldir=/usr/local/openssl-0.9.6d The output from that was: Operating system: sun4u-whatever-solaris2 ./config: test: unknown operator (GCC) The config script is dated Mar 15 08:47 (which I think is 15:47 GMT, since I'm in California and we're on Daylight Savings Time). Its size is 17352 bytes. The line that errors out for me is line 613: if [ $OUT = solaris-sparcv9-gcc -a $GCCVER -lt 28 ] I put the following in front of it to see the value of GCCVER: echo GCCVER = \$GCCVER\; exit and got this output: Operating system: sun4u-whatever-solaris2 GCCVER = gcc (GCC) 31 With the value of GCCVER having embedded whitespace, you can see why test would give up on it. I hope this helps. Let me know if you need anything else from me. -Allen Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Thu, 13 Jun 2002 14:52:11 -0700, Allen Hopkins [EMAIL PROTECTED] said: allenh I'm afraid this was not a fix. Have you tried it with gcc-3.1? allenh I encountered this problem with the 0.9.6d snapshot. I tried it just now, GCCVER becamse 31, and my output was -- gcc (GCC) 3.1.1 20020606 (Debian prerelease) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- -- 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 #89] missing prototypes for functions
Ok, I have now finished applying the patches including the changed prototypes for ASN1 using the DECLARE macro. Please test the next snapshot (or beta2, which will probably be built on Sunday evening). Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #96] problem config
Hi openssl-dev, ~~/src/openssl-0.9.6d.src root@galilee gcc --version gcc (GCC) 3.1 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. vi config 383 # figure out if gcc is available and if so we use it otherwise 384 # we fallback to whatever cc does on the system 385 GCCVER=`(gcc --version) 2/dev/null` 386 if [ $GCCVER != ]; then 387CC=gcc 388# then strip off whatever prefix Cygnus prepends the number with... 389GCCVER=`echo $GCCVER | sed 's/^[a-z]*\-//'` 390GCCVER=`echo $GCCVER | sed 's/(GCC)//'` 391GCCVER=`echo $GCCVER | sed 's/^[a-z]*//'` 392# peak single digit before and after first dot, e.g. 2.95.1 gives 29 393GCCVER=`echo $GCCVER | sed 's/\([0-9]\)\.\([0-9]\).*/\1\2/'` 394 else 395CC=cc 396 fi ... Add line 390, 391 -- Regards CETELEM - Equipe système Unix / Xnet. [2-2329] Eric Vanborren 20 av. Georges Pompidou - 92595 Levallois Perret - FRANCE Tél: +33 1.46.39.2329 - e-mail: [EMAIL PROTECTED] May The OpenSource be with you ! __ 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: can't compile on solaris 9 - gcc
On Thu, Jun 13, 2002 at 03:46:42PM +, Gustavo A. Baratto wrote: I'm not being successful in compiling openssl-0.9.6d on solaris 9 with gcc 3.1. We are aware that problems exist with respect to GCC 3.1. Several different changes to config have been proposed and one fix has already been applied to the snapshots. Discussion is however not closed, yet: http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=96 Best regards, Lutz -- 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 #96] bug in config script (gcc 3.1)
Different solutions have been proposed and I am not sure whether the currently checked in version will finally work. I am not sure for how long -dumpversion was supported (at least since 1994 as was reported) and I strongly consider to use -dumpversion. Richard: you seem to have a beta version of 3.1.1 around. Will its output for -dumpversion somehow fit into the model? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #97] About 0.9.6a(b) and des_encrypt1()
On Fri, Jun 14, 2002 at 08:34:06PM +0200, Jani Taskinen via RT wrote: On Fri, 14 Jun 2002, Lutz Jaenicke via RT wrote: This problem has been resolved for 0.9.7... Great. Is it worthwile to make a small adjustment for 0.9.6e (in case it will be released)? If 0.9.7 is due to be released soon (?) then I don't think that's necessary..but of course if there will be another release of 0.9.6 then it would be nice to have this in it. There will not be another release of 0.9.6 before 0.9.7 will be out. We still maintain the 0.9.6 tree, because we anticipate that due to incompatible changes between 0.9.6 and 0.9.7 several people will stay with 0.9.6x for some more time, so we are prepared to release another 0.9.6e version, if important bugs are found. It is however not clear, whether there will really be a 0.9.6e release. If 0.9.7 is accepted fast by our user base, it will never appear. The change that is required will break binary compatibility between 0.9.6d and 0.9.6e (because that's the purpose of the change :-). Even though we try to make clear that we don't promise binary compatibility, a lot of people expect it. I am therefore a bit reluctant to make the change and will keep the issue as an open ticket in the request tracker, until 0.9.6e becomes reality or some other member of the team makes a final decision. Best regards, Lutz -- 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]
Re: [openssl.org #96] bug in config script (gcc 3.1)
I agree that simply using -dumpversion makes more sense, on the assumption that it will always only output the number. --version appears to be intended to be human-readable, not machine-readable, and its format may change at any time, as it just did. Why keep adding sed commands that say, oh, and if it has this in front of it, get rid of that, too? It might just break again with the next gcc version. Having said that, I think I'll bow out of the discussion. I'm just an end-user, and may never have to install it again. -Allen Lutz Jaenicke via RT wrote: Different solutions have been proposed and I am not sure whether the currently checked in version will finally work. I am not sure for how long -dumpversion was supported (at least since 1994 as was reported) and I strongly consider to use -dumpversion. Richard: you seem to have a beta version of 3.1.1 around. Will its output for -dumpversion somehow fit into the model? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL engine ctrl: handling of strings
Hello folks,
There is a possible problem with the string param handling of ENGINE_ctrl():
(At least I will get a problem...)
In the ..._ctrl()-Function of the engines a passed string
is only referenced and not copyed.
This is bad if the buffer with the passed data is overwritten...
Since in the BIO interface passed string params are copied
to an internal (allocated) buffer (at least in the modules I
checked...), the ENGINE -interface should act the same way.
Please have a look at the attached patch...
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
diff -r openssl-0.9.7-stable-SNAP-20020613/crypto/engine/eng_dyn.c
openssl-0.9.7-stable-SNAP-20020613_new/crypto/engine/eng_dyn.c
159a160,163
if (ctx-DYNAMIC_LIBNAME)
OPENSSL_free((void*)(ctx-DYNAMIC_LIBNAME));
if (ctx-engine_id)
OPENSSL_free((void*)(ctx-engine_id));
172c176
if(!ctx)
---
if(!c)
313,314c317,323
ctx-DYNAMIC_LIBNAME = (const char *)p;
return 1;
---
if (ctx-DYNAMIC_LIBNAME)
OPENSSL_free((void*)(ctx-DYNAMIC_LIBNAME));
if (p)
ctx-DYNAMIC_LIBNAME = BUF_strdup(p);
else
ctx-DYNAMIC_LIBNAME = NULL;
return ctx-DYNAMIC_LIBNAME != NULL ? 1 : 0;
322,323c331,337
ctx-engine_id = (const char *)p;
return 1;
---
if (ctx-engine_id)
OPENSSL_free((void*)(ctx-engine_id));
if (p)
ctx-engine_id = BUF_strdup(p);
else
ctx-engine_id = NULL;
return ctx-engine_id != NULL ? 1 : 0;
diff -r openssl-0.9.7-stable-SNAP-20020613/crypto/engine/hw_4758_cca.c
openssl-0.9.7-stable-SNAP-20020613_new/crypto/engine/hw_4758_cca.c
127,128c127,147
static const char def_CCA4758_LIB_NAME[] = CCA_LIB_NAME;
static const char *CCA4758_LIB_NAME = def_CCA4758_LIB_NAME;
---
static const char *CCA4758_LIB_NAME = NULL;
static const char *get_CCA4758_LIB_NAME()
{
if (CCA4758_LIB_NAME)
return CCA4758_LIB_NAME;
else
return CCA_LIB_NAME;
}
static void free_CCA4758_LIB_NAME()
{
if (CCA4758_LIB_NAME)
OPENSSL_free((char*)CCA4758_LIB_NAME);
CCA4758_LIB_NAME = NULL;
}
static long set_CCA4758_LIB_NAME(const char *newName)
{
if (CCA4758_LIB_NAME)
OPENSSL_free((char*)CCA4758_LIB_NAME);
return (CCA4758_LIB_NAME = BUF_strdup(newName)) != NULL ? 1 : 0;
}
234a254
free_CCA4758_LIB_NAME();
246c266
dso = DSO_load(NULL, CCA4758_LIB_NAME , NULL, 0);
---
dso = DSO_load(NULL, get_CCA4758_LIB_NAME() , NULL, 0);
302c322,323
if(dso)
---
free_CCA4758_LIB_NAME();
if(!dso)
322c343
return 1;
---
return 1;
343,344c364
CCA4758_LIB_NAME = (const char *)p;
return 1;
---
return set_CCA4758_LIB_NAME((const char*)p);
diff -r openssl-0.9.7-stable-SNAP-20020613/crypto/engine/hw_aep.c
openssl-0.9.7-stable-SNAP-20020613_new/crypto/engine/hw_aep.c
73a74
#include openssl/buffer.h
366c367,386
static const char *AEP_LIBNAME = aep;
---
static const char *AEP_LIBNAME = NULL;
static const char *get_AEP_LIBNAME()
{
if (AEP_LIBNAME)
return AEP_LIBNAME;
else
return aep;
}
static void free_AEP_LIBNAME()
{
if (AEP_LIBNAME)
OPENSSL_free((char*)AEP_LIBNAME);
AEP_LIBNAME = NULL;
}
static long set_AEP_LIBNAME(const char *newName)
{
if (AEP_LIBNAME)
OPENSSL_free((char*)AEP_LIBNAME);
return (AEP_LIBNAME = BUF_strdup(newName)) != NULL ? 1 : 0;
}
415c435
aep_dso = DSO_load(NULL, AEP_LIBNAME, NULL, 0);
---
aep_dso = DSO_load(NULL, get_AEP_LIBNAME(), NULL, 0);
476a497
free_AEP_LIBNAME();
485a507
free_AEP_LIBNAME();
552,553c574
AEP_LIBNAME = (const char *)p;
return 1;
---
return set_AEP_LIBNAME((const char*)p);
diff -r openssl-0.9.7-stable-SNAP-20020613/crypto/engine/hw_atalla.c
openssl-0.9.7-stable-SNAP-20020613_new/crypto/engine/hw_atalla.c
289,290c289,309
static const char def_ATALLA_LIBNAME[] = atasi;
static const char *ATALLA_LIBNAME = def_ATALLA_LIBNAME;
---
static const char *ATALLA_LIBNAME = NULL;
static const char *get_ATALLA_LIBNAME()
{
if (ATALLA_LIBNAME)
return ATALLA_LIBNAME;
else
return atasi;
}
static void free_ATALLA_LIBNAME()
{
if (ATALLA_LIBNAME)
OPENSSL_free((char*)ATALLA_LIBNAME);
ATALLA_LIBNAME = NULL;
}
static long set_ATALLA_LIBNAME(const char *newName)
{
if (ATALLA_LIBNAME)
OPENSSL_free((char*)ATALLA_LIBNAME);
return (ATALLA_LIBNAME = BUF_strdup(newName) )!= NULL ? 1 : 0;
}
301a321
free_ATALLA_LIBNAME();
327c347
[openssl.org #98] OpenSSL engine ctrl: handling of strings
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: can't compile on solaris 9 - gcc
Thank you for your answer... I got the latest CVS and the config works fine now. great work you guys are doing. On Fri, 2002-06-14 at 19:09, Lutz Jaenicke wrote: On Thu, Jun 13, 2002 at 03:46:42PM +, Gustavo A. Baratto wrote: I'm not being successful in compiling openssl-0.9.6d on solaris 9 with gcc 3.1. We are aware that problems exist with respect to GCC 3.1. Several different changes to config have been proposed and one fix has already been applied to the snapshots. Discussion is however not closed, yet: http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=96 Best regards, Lutz -- 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] -- -- Gustavo Baratto - Programming and Technical Support [EMAIL PROTECTED] * (604) 638-2525 ext. 408 Technical support web-site: http://support.superb.net Superb Internet Corp. Ahead of the Rest - __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #97] About 0.9.6a(b) and des_encrypt1()
On Fri, 14 Jun 2002, Lutz Jaenicke via RT wrote: There will not be another release of 0.9.6 before 0.9.7 will be out. We still maintain the 0.9.6 tree, because we anticipate that due to incompatible changes between 0.9.6 and 0.9.7 several people will stay with 0.9.6x for some more time, so we are prepared to release another Perfectly understandable. btw. is there any list of those changes anywhere? Just thinking if there are some issues we should be aware of with PHP's openssl extension.. The change that is required will break binary compatibility between 0.9.6d and 0.9.6e (because that's the purpose of the change :-). Even though we try to make clear that we don't promise binary compatibility, a lot Heh, of course. of people expect it. I am therefore a bit reluctant to make the change and will keep the issue as an open ticket in the request tracker, until 0.9.6e becomes reality or some other member of the team makes a final decision. For me it's okay to close this. I've already told the people who reported this problem to bugs.php.net that this is fixed in openssl 0.9.7.. :) --Jani __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #97] About 0.9.6a(b) and des_encrypt1()
[[EMAIL PROTECTED] - Fri Jun 14 22:02:06 2002]: On Fri, 14 Jun 2002, Lutz Jaenicke via RT wrote: There will not be another release of 0.9.6 before 0.9.7 will be out. We still maintain the 0.9.6 tree, because we anticipate that due to incompatible changes between 0.9.6 and 0.9.7 several people will stay with 0.9.6x for some more time, so we are prepared to release another Perfectly understandable. btw. is there any list of those changes anywhere? Just thinking if there are some issues we should be aware of with PHP's openssl extension.. There is a change in the EVP interface: appliations must now call EVP_CIPHER_CTX_cleanup() explicitly. Up to and including 0.9.6x, all data was part of the EVP_CIPHER_CTX, starting with 0.9.7, some data are allocated on the fly and memory leaks may occur, if the cleanup is not called. The OID (Object Identifier) table has experienced some changes to become conformant to RFC2256 (LDAP). Some entries had to be renamed. For me it's okay to close this. I've already told the people who reported this problem to bugs.php.net that this is fixed in openssl 0.9.7.. :) Ok, case closed. Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/evp c_all.c evp.h
In message [EMAIL PROTECTED] on Fri, 14 Jun 2002 20:59:59
+0200 (MET DST), [EMAIL PROTECTED] said:
jaenicke diff -u -r1.7.8.1 -r1.7.8.2
jaenicke --- c_all.c 2002/02/23 02:09:25 1.7.8.1
jaenicke +++ c_all.c 2002/06/14 18:59:53 1.7.8.2
jaenicke @@ -61,6 +61,7 @@
jaenicke#include openssl/evp.h
jaenicke
jaenicke#undef OpenSSL_add_all_algorithms
jaenicke +void OpenSSL_add_all_algorithms(void);
jaenicke
jaenickevoid OpenSSL_add_all_algorithms(void)
jaenicke {
Please explain why you need to declare that function just before you
define it. I can't see how that makes sense...
--
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 #96] bug in config script (gcc 3.1)
In message [EMAIL PROTECTED] on Fri, 14 Jun 2002 21:14:43 +0200 (METDST), Lutz Jaenicke via RT [EMAIL PROTECTED] said: rt Richard: you seem to have a beta version of 3.1.1 around. Will its rt output for -dumpversion somehow fit into the model? : ; gcc -dumpversion 3.1.1 I see no problem. -- 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 #75] DJGPP (DOS) Patch for 0.9.7
On Thu, 13 Jun 2002, Doug Kaufman wrote:
On Thu, 13 Jun 2002, Richard Levitte via RT wrote:
I finally committed most of your changes. Please download the next
snapshot of 0.9.7 and check that it works as intended.
I'm keeping this ticket open until you have confirmed that it works
(perhaps after further changes).
Thanks. I'll try to do this in the next few days.
The snapshot doesn't work under DJGPP, but I think that this patch
will fix it. There were several problems. In Configure, you tried to
use ENV{DJDIR}, but this puts in a DOS style path such as c:/djgpp.
The extra : throws off each of the subsequent parameters by one
field. This was one of the reasons that the /dev/env notation was
developed. make depend gave quite a few warnings, since the include
directives from CFLAG were not utilized. This led to a number of
header files not being found under DJGPP (and presumably for anyone
else not using standard locations for header files). This patch
adds the CFLAG directives for make depend. Lastly, as I mentioned
previously, make depend doesn't fix the problem of no testfiles for
excluded algorithms, so compilation stops with errors in the test
directory, even after running make depend.
I think I finally came up with an acceptable method of putting the
header and test files for excluded algoritms in include/openssl and
test respectively. If this is accepted, there should be no need to
run make depend after excluding algorithms. I didn't put it in the
patch, but I would consider removing the notice to run make depend,
which was just added.
I also found a problem I had previously overlooked in
crypto/engine/hw_aep.c. Which MSDOS compiler needs the section that
doesn't apply to DJGPP?
With this patch, the snapshot from 13 June does Configure, make, and
make test without problems under DJGPP. make depend also completes
without warnings, but it doesn't seem necessary to run it.
Patch attached to avoid problems with long lines in the archive.
Doug
__
Doug Kaufman
Internet: [EMAIL PROTECTED]
--- openssl-0.9.7/Configure.orig2002-06-13 22:07:24.0 +
+++ openssl-0.9.7/Configure 2002-06-14 20:03:22.0 +
@@ -517,7 +517,7 @@
Cygwin, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486
-Wall:::CYGWIN32::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}:win32:cygwin-shared:::.dll,
# DJGPP
-DJGPP, gcc:-I/dev/env/DJDIR/watt32/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer
-O2 -Wall:::MSDOS:-L$ENV{DJDIR}/watt32/lib -lwatt:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}::,
+DJGPP, gcc:-I/dev/env/DJDIR/watt32/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer
+-O2 -Wall:::MSDOS:-L/dev/env/DJDIR/watt32/lib -lwatt:BN_LLONG ${x86_gcc_des}
+${x86_gcc_opts}::,
# Ultrix from Bernhard Simon [EMAIL PROTECTED]
ultrix-cc,cc:-std1 -O -Olimit 1000 -DL_ENDIAN::(unknown):::,
@@ -1438,10 +1438,14 @@
} else {
my $make_command = make -f Makefile.ssl PERL=\'$perl\';
my $make_targets = ;
+ my $skip_dir;
$make_targets .= links if $symlink;
$make_targets .= depend if $depflags ne $make_depend;
(system $make_command.$make_targets) == 0 or exit $?
if $make_targets ne ;
+ foreach $skip_dir (@skip) {
+ system (cd crypto/$skip_dir; make links PERL=\'$perl\' -f Makefile.ssl);
+}
if ( $perl =~ m@^/@) {
dofile(tools/c_rehash,$perl,'^#!/', '#!%s','^my \$dir;$', 'my $dir = '
. $openssldir . ';');
dofile(apps/der_chop,$perl,'^#!/', '#!%s');
--- openssl-0.9.7/Makefile.org.orig 2002-06-12 05:02:08.0 -0800
+++ openssl-0.9.7/Makefile.org 2002-06-14 07:52:36.0 -0800
@@ -598,7 +598,7 @@
do \
if [ -d $$i ]; then \
(cd $$i echo making dependencies $$i... \
- $(MAKE) SDIRS='${SDIRS}' DEPFLAG='${DEPFLAG}'
MAKEDEPPROG='${MAKEDEPPROG}' KRB5_INCLUDES='${KRB5_INCLUDES}' PERL='${PERL}' depend )
|| exit 1; \
+ $(MAKE) SDIRS='${SDIRS}' CFLAG='${CFLAG}' DEPFLAG='${DEPFLAG}'
+MAKEDEPPROG='${MAKEDEPPROG}' KRB5_INCLUDES='${KRB5_INCLUDES}' PERL='${PERL}' depend )
+|| exit 1; \
fi; \
done;
--- openssl-0.9.7/crypto/Makefile.ssl.orig 2002-06-10 04:04:58.0 -0800
+++ openssl-0.9.7/crypto/Makefile.ssl 2002-06-14 07:38:20.0 -0800
@@ -141,7 +141,7 @@
@for i in $(SDIRS) ;\
do \
(cd $$i echo making depend in crypto/$$i... \
- $(MAKE) MAKEFILE='${MAKEFILE}' INCLUDES='${INCLUDES}' DEPFLAG='${DEPFLAG}'
PERL='${PERL}' depend ); \
+ $(MAKE) MAKEFILE='${MAKEFILE}' INCLUDES='${INCLUDES}' CFLAG='${CFLAG}'
+DEPFLAG='${DEPFLAG}' PERL='${PERL}' depend ); \
done;
clean:
--- openssl-0.9.7/crypto/engine/hw_aep.c.orig 2002-03-07 20:07:44.0 +
+++ openssl-0.9.7/crypto/engine/hw_aep.c
Re: [openssl.org #75] DJGPP (DOS) Patch for 0.9.7
On Fri, 14 Jun 2002, Doug Kaufman wrote:
With this patch, the snapshot from 13 June does Configure, make, and
make test without problems under DJGPP. make depend also completes
without warnings, but it doesn't seem necessary to run it.
Patch attached to avoid problems with long lines in the archive.
It looks like I sent a patch with DOS eol's. Here is the patch in better
format. Sorry.
Doug
__
Doug Kaufman
Internet: [EMAIL PROTECTED]
--- openssl-0.9.7/Configure.orig2002-06-13 22:07:24.0 +
+++ openssl-0.9.7/Configure 2002-06-14 20:03:22.0 +
@@ -517,7 +517,7 @@
Cygwin, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486
-Wall:::CYGWIN32::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}:win32:cygwin-shared:::.dll,
# DJGPP
-DJGPP, gcc:-I/dev/env/DJDIR/watt32/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer
-O2 -Wall:::MSDOS:-L$ENV{DJDIR}/watt32/lib -lwatt:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}::,
+DJGPP, gcc:-I/dev/env/DJDIR/watt32/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer
+-O2 -Wall:::MSDOS:-L/dev/env/DJDIR/watt32/lib -lwatt:BN_LLONG ${x86_gcc_des}
+${x86_gcc_opts}::,
# Ultrix from Bernhard Simon [EMAIL PROTECTED]
ultrix-cc,cc:-std1 -O -Olimit 1000 -DL_ENDIAN::(unknown):::,
@@ -1438,10 +1438,14 @@
} else {
my $make_command = make -f Makefile.ssl PERL=\'$perl\';
my $make_targets = ;
+ my $skip_dir;
$make_targets .= links if $symlink;
$make_targets .= depend if $depflags ne $make_depend;
(system $make_command.$make_targets) == 0 or exit $?
if $make_targets ne ;
+ foreach $skip_dir (@skip) {
+ system (cd crypto/$skip_dir; make links PERL=\'$perl\' -f Makefile.ssl);
+}
if ( $perl =~ m@^/@) {
dofile(tools/c_rehash,$perl,'^#!/', '#!%s','^my \$dir;$', 'my $dir = '
. $openssldir . ';');
dofile(apps/der_chop,$perl,'^#!/', '#!%s');
--- openssl-0.9.7/Makefile.org.orig 2002-06-12 05:02:08.0 -0800
+++ openssl-0.9.7/Makefile.org 2002-06-14 07:52:36.0 -0800
@@ -598,7 +598,7 @@
do \
if [ -d $$i ]; then \
(cd $$i echo making dependencies $$i... \
- $(MAKE) SDIRS='${SDIRS}' DEPFLAG='${DEPFLAG}'
MAKEDEPPROG='${MAKEDEPPROG}' KRB5_INCLUDES='${KRB5_INCLUDES}' PERL='${PERL}' depend )
|| exit 1; \
+ $(MAKE) SDIRS='${SDIRS}' CFLAG='${CFLAG}' DEPFLAG='${DEPFLAG}'
+MAKEDEPPROG='${MAKEDEPPROG}' KRB5_INCLUDES='${KRB5_INCLUDES}' PERL='${PERL}' depend )
+|| exit 1; \
fi; \
done;
--- openssl-0.9.7/crypto/Makefile.ssl.orig 2002-06-10 04:04:58.0 -0800
+++ openssl-0.9.7/crypto/Makefile.ssl 2002-06-14 07:38:20.0 -0800
@@ -141,7 +141,7 @@
@for i in $(SDIRS) ;\
do \
(cd $$i echo making depend in crypto/$$i... \
- $(MAKE) MAKEFILE='${MAKEFILE}' INCLUDES='${INCLUDES}' DEPFLAG='${DEPFLAG}'
PERL='${PERL}' depend ); \
+ $(MAKE) MAKEFILE='${MAKEFILE}' INCLUDES='${INCLUDES}' CFLAG='${CFLAG}'
+DEPFLAG='${DEPFLAG}' PERL='${PERL}' depend ); \
done;
clean:
--- openssl-0.9.7/crypto/engine/hw_aep.c.orig 2002-03-07 20:07:44.0 +
+++ openssl-0.9.7/crypto/engine/hw_aep.c2002-06-14 20:22:30.0 +
@@ -60,7 +60,7 @@
#include string.h
#include openssl/e_os2.h
-#ifndef OPENSSL_SYS_MSDOS
+#if !defined(OPENSSL_SYS_MSDOS) || defined(__DJGPP__)
#include sys/types.h
#include unistd.h
#else
--- openssl-0.9.7/util/domd.orig2002-06-05 00:09:16.0 -0800
+++ openssl-0.9.7/util/domd 2002-06-14 07:54:22.0 -0800
@@ -17,7 +17,7 @@
if [ $MAKEDEPEND = gcc ]; then
sed -e '/^# DO NOT DELETE.*/,$d' Makefile.ssl Makefile.tmp
echo '# DO NOT DELETE THIS LINE -- make depend depends on it.' Makefile.tmp
-gcc -D OPENSSL_DOING_MAKEDEPEND -M $@ Makefile.tmp
+gcc -D OPENSSL_DOING_MAKEDEPEND -M ${CFLAG} $@ Makefile.tmp
${PERL} $TOP/util/clean-depend.pl Makefile.tmp Makefile.new
rm -f Makefile.tmp
else
