security problem with openssl-0.9.6f and below?
Hi, A friend of mine forwarded the ChangeLog from 0.9.6g, it mentioned an ASN.1 parser fix but didn't really say whether there were any security implications with it. Just about everyone had to do a massive update to 0.9.6e last week, I was wondering whether the bug was serious enough to make the public aware via the normal channels (mailing lists, etc). As far as I could tell, the bug allows someone to specify an ASN.1 value whose length would be 4 bytes longer than the actual buffer. To do anything interesting with this, they would have to have this value as the last one (entity?) in the buffer being parsed, otherwise the read will start 4 bytes into the next chunk and it will error when it tries to parse it. An easy way to test for the bug: perl -e 'print \x02\x7f . (A x 123)' | /usr/local/ssl/bin/openssl \ asn1parse -inform DER The last bytes are all 0 on systems running 0.9.6e and below, while the latest version gives the correct error message (ASN1_get_object:too long). Can anyone think of a case where this could be used to exploit an application using openssl? For instance, the asn1_parse2 function relies on the len value for all sorts of things. I can't see an easy way to abuse the bug into crashing anything, since the values read at the end of the buffer will most likely be all nulls or in the worst case random values from memory. Anyways, I will keep playing with it, just wanted to see what yall's take on it was ;) -HD __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #224] sc_clnt.c changes from 0.9.6d to 0.9.6g
Sorry, I don't know exactly which version these changes were made in.
I am upgrading from version `d' to version `g'.
I have the following differences in s3_clnt.c. The problems are that
the cryptlib.h header is in the crypto directory. Should I put this
on the include path when building the SSL library or would it make
more sense to use the openssl copy. Ie, change,
`#include cryptlib.h'
to
`#include openssl/cryptlib.h'
The other thing is that the sizeof operation produces an unsigned
int and the variables they are being compared to are ints. So I
changed this,
+ if (i sizeof s-session-session_id)
to
+ if (i (int)sizeof s-session-session_id)
I am compiling the libraries with GCC 2.7.9-970819 egcs-971225
tornado 2.0 and have all warnings and treat them as errors (-Wall
-Werror). Are the *nix version compiling with warnings? Perhaps the
cast should have been on `i', now that I think about it as the
structure size is invariant (and less than MAX_INT).
There are a few other things, but porting between versions is pretty
easy.
Thanks,
Bill Pringlemeir.
*** c:/TEMP/s3_clnt.c.~1.2~ Wed Aug 14 17:09:00 2002
--- c:/TEMP/s3_clnt.c Wed Aug 14 17:09:00 2002
***
*** 117,122
--- 117,123
#include ssl_locl.h
+ #include cryptlib.h
static SSL_METHOD *ssl3_get_client_method(int ver);
***
*** 545,550
--- 546,556
if (i != 0)
{
+ if (i (int)sizeof s-session-session_id)
+ {
+ SSLerr(SSL_F_SSL3_CLIENT_HELLO, SSL_R_INTERNAL_ERROR);
+ goto err;
+ }
memcpy(p,s-session-session_id,i);
p+=i;
}
***
*** 625,630
--- 631,644
/* get the session-id */
j= *(p++);
+
+if(j sizeof s-session-session_id)
+{
+al=SSL_AD_ILLEGAL_PARAMETER;
+SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,
+ SSL_R_SSL3_SESSION_ID_TOO_LONG);
+goto f_err;
+}
if ((j != 0) (j != SSL3_SESSION_ID_SIZE))
{
--
It is reasoning and faith that bind truth . - Rod Ryker...
__
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 #224] sc_clnt.c changes from 0.9.6d to 0.9.6g
[[EMAIL PROTECTED] - Thu Aug 15 09:21:57 2002]: I have the following differences in s3_clnt.c. The problems are that the cryptlib.h header is in the crypto directory. Should I put this on the include path when building the SSL library or would it make more sense to use the openssl copy. Ie, change, `#include cryptlib.h' to `#include openssl/cryptlib.h' I'm sorry, I don't understand what the problem is. the first above variant of the #include is the correct one, since cryptolib.h is a OpenSSL-internal header file (if you look in include/openssl, you'll see that it doesn't exist there). -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #223] Length error in EVP_DecodeBlock
[[EMAIL PROTECTED] - Wed Aug 14 22:36:47 2002]:
EVP_DecodeBlock() [in crypto/evp/encode.c] returns the length of
the
result
of the base-64 decode. However this length is not the true length
of
the
result but includes any trailing fills ('=') so it's always 0 mod
3.
This
obviously can cause errors in any processing on the result, e.g.
decryption.
I would suggest that adding something like:
while (*--f == '=')
--ret;
immediately before the return(ret); would solve the problem.
Well, depends. If you consider that EVP_DecodeBlock() really just
is a helper function for EVP_DecodeUpdate(), the implementation is
correct, and you're change would actually break EVP_DecodeUpdate()
as well as any call to EVP_DecodeBlock() that expects the current
behavior. You see, EVP_DecodeUpdate() checks for the final '=' and
decreases the final length accordingly. You need to do the same.
This ticket is resolved.
--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Wed, Aug 14, 2002 at 08:42:47PM +0100, Ben Laurie wrote: I propose we have a compile time flag that determines whether impossible conditions are fatal or return errors, Go ahead, compile time flags are how we usually handle such things in OpenSSL -- e.g. you can define BN_DEBUG to enable certain assertions that detect situations where memory is really corrupted. Good. Now we have to debate what the default setting of the flag is. I propose, naturally, that it should be set to cause death on internal errors. Whatever decision we make, the same scheme should also be applied to asserts found elsewhere in the library. The current pattern is to define NDEBUG unless the respective DEBUG option is set. As you noted that assert() (with output to stderr) may be more dangerous than a straight abort(), the new OpenSSL_assert() macro (as it might be called) should be used everywhere in place of assert() (except possibly when a DEBUG option is set). -- 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 #221] for ARM
[[EMAIL PROTECTED] - Wed Aug 14 10:43:15 2002]: I build it at a Linux RedHat R7.2 i386 machine, it build ok. I just find the crypts subdirectory have some asm directory. Not try to compile by cross-compile yet. A quick answer: there is currently no assembler code for ARM in OpenSSL. If you need to compile it on a i386-linux system, you need to configure with the option 'no-asm'. Did that answer your question? -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #220] bug in config (openssl-0.9.6g, Solaris2.6)
[guest - Tue Aug 13 16:21:38 2002]: In the case 'sun4u*-*-solaris2 stating on line 567 of file config, OUT is set to 'solaris-sparcv9-$CC' even if ISA64 does not contain sparcv9. I do not think this is done deliberately. Please help us, what should the target be in that case? solaris-sparcv8-$CC? -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #218] Cluster Labs engine implementation
I have placed your patch in http://www.openssl.org/contrib, named openssl_cluster-labs-0.9.7-beta3.patch.gz. In 0.9.7, I've also placed relevant files from your patch in demos/engines/cluster_labs, where it can be built as a shared library, and be useful that way. It remains to be seen how things will be handled in 0.9.8. This ticket is now resolved. [guest - Tue Aug 13 13:19:55 2002]: Hello, We have implemented an engine for our CRP310 and CRP410 SSL hardware accelerator devices. This card supports up to now RSA, DSA, DH and RAND. I will send you a patchfile for openssl-0.9.7beta3 with all changes in ./crypto/engine. We have a patch for the older versions 0.9.6 too. Should I commit them? We have compiled this openssl code with the following systems Linux 2.4 (gcc 2.96) Solaris 2.8 (Sun Workshop 6.0 C 5.1) Solaris 2.6 (gcc3.1) It would be great if you can implement the code into one of the next openssl versions. Best regards Jan Tschirschwitz -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #204] minor problem with openssl.spec file
We won't change our openssl.spec, so I'm going to resolve this ticket. [[EMAIL PROTECTED] - Sat Aug 10 00:01:22 2002]: In message [EMAIL PROTECTED] on Fri, 9 Aug 2002 18:46:24 +0200 (METDST), download (Jim Prewett) via RT [EMAIL PROTECTED] said: rt I'm sorry to bother you again, but check this out: rt rt http://www.redhat.com/swr/i686/openssl-0.9.6b-18.i686_dp.html rt rt Which says: rt rt Provides rt The following virtual packages are provided in this package. rt rt openssl libcrypto.so.2 rt libssl.so.2 openssl Those are made with a different openssl.spec, *made by RedHat*. They've done quite a bit of work with that before OpenSSL had any shared library support at all. I don't recall the specific details, and will probably not have the time to investigate further before the end of september. All I know is that there have been some reports saying that trying to replace libcrypto.so.2 and libssl.so.2 with something that one has compiled oneself just doesn't work. It's possible this has changed. Unfortunately, I'm not a RedHat user, and I don't have any RedHat system to play with, so I can't try doing this myself. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #201] OpenSSL 0.9.6e failing make test
The only thing I can think of is that your disk is full, or test/testreq.pem is corrupted in some way. [[EMAIL PROTECTED] - Wed Aug 7 13:15:20 2002]: Hello, On my old Linux box (Intel Debian bo: kernel 2.0.39, gcc 2.7.2.1, libc 5.4.33) during OpenSSL 0.9.6e build a test in make test fails: | testing req conversions | p - d | make[1]: *** [test_req] Error 1 | make: *** [tests] Error 2 I'm not a build process expert (really not), so I don't know what to do next as test... I tried O.9.6d: got exactly the same problem. Output of make report comes attached. Please CC me, I'm not subscribed. Alain. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #199] Bugs
Interesting bc failure! My suggestion is that you download and compile GNU bc, install it in some private directory and include that directory in your $PATH, then redo the test. I consider this ticket resolved. [[EMAIL PROTECTED] - Tue Aug 6 17:38:27 2002]: OpenSSL self-test report: OpenSSL version: 0.9.6d Last change: Fix crypto/asn1/a_sign.c so that 'parameters' is omitte... OS (uname): dgux leda R4.20MU05 generic AViiON PentiumPro OS (config): AViiON-dg-dgux Target (default): dgux Target: gcc Compiler: gcc version 2.7.2 (ix86 DG/ux, DG-2.7.2.9, Feb 3 1998) Failure! [...] testlog -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #217] bug in util/pod2mantest (openssl-0.9.6g)
Ticket 207 is resolved, too (if pod2mantest finds a working pod2man, this is now called directly without explicitly invoking perl). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #198] Bug Report
[[EMAIL PROTECTED] - Tue Aug 6 17:38:02 2002]: Ive installed and configurd all of the above, and have gotten to the apache build process and encounter the following error: /usr/lib/libssl.a(ssl_cert.o): In function `ssl_verify_cert_chain': ssl_cert.o(.text+0xbab): undefined reference to `X509_STORE_CTX_set_verify_cb' /usr/lib/libssl.a(ssl_algs.o): In function `SSL_library_init': ssl_algs.o(.text+0x2d): undefined reference to `EVP_idea_cbc' collect2: ld returned 1 exit status Could you show us the compiling line above that error? It looks to me like -lcrypto has been forgotten or misplaces. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #196] Misc. fixes for OpenSSL 0.9.7 beta3
[[EMAIL PROTECTED] - Mon Aug 5 20:53:24 2002]: Hi, I have a few minor fixes for OpenSSL 0.9.7 beta3, in summary: - I keep a local CVS repository, and would prefer the generated/linked files *not* to be present in the distributed archive. The enclosed diffs indicate which files these are. I've also added .cvsignore files; see the archive of added files. You mean our actual distributions? I'm not sure about that. Our snapshots should be free of generated files and links. Or are you talking about the files produced by 'make update'? You can forget that' I'm afraid. - A perl script for generating HTML documentation from the .pod files. Interesting, I might get some time to look at it in a month (I've something similar which is used to generated our HTML-ified manual pages). - Missing =back in SSL_CTX_set_msg_callback.pod Fix applied. Thanks. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #199] Bugs
[EMAIL PROTECTED]: Failure! [...] Failed! bc: stack empty Can you condense the bc test file into a single-line test so that we can automatically test if bc has this bug? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2mantest
In message [EMAIL PROTECTED] on Wed, 14 Aug 2002 16:10:31 +0200 (MET DST), [EMAIL PROTECTED] said: bodo bodo14-Aug-2002 16:10:29 bodo bodo Modified:.Tag: OpenSSL_0_9_6-stable Makefile.org bodoutil Tag: OpenSSL_0_9_6-stable pod2mantest bodo Log: bodo change how pod2man is handled: explicitly invoke '$PERL' only when bodo needed, call 'pod2man' directly if this works bodo bodo PR: 217 Doesn't this change solve PR 207 as well? -- Richard Levitte [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~levitte/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #220] bug in config (openssl-0.9.6g, Solaris2.6)
Since isalist displays the available native instruction sets ordered in the sense of best performance, I guess the best choice for target would be the leftmost in the list displayed. Under no circumstances should the target be set to something which is not available on the respective platform. Agree? Or did I completely misunderstand something there? :-) giovari [levitte - Thu Aug 15 11:56:30 2002]: [guest - Tue Aug 13 16:21:38 2002]: In the case 'sun4u*-*-solaris2 stating on line 567 of file config, OUT is set to 'solaris-sparcv9-$CC' even if ISA64 does not contain sparcv9. I do not think this is done deliberately. Please help us, what should the target be in that case? solaris-sparcv8-$CC? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #196] Misc. fixes for OpenSSL 0.9.7 beta3
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Richard Levitte via RT Sent: Thursday, August 15, 2002 13:06 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #196] Misc. fixes for OpenSSL 0.9.7 beta3 [[EMAIL PROTECTED] - Mon Aug 5 20:53:24 2002]: Hi, I have a few minor fixes for OpenSSL 0.9.7 beta3, in summary: - I keep a local CVS repository, and would prefer the generated/linked files *not* to be present in the distributed archive. The enclosed diffs indicate which files these are. I've also added .cvsignore files; see the archive of added files. You mean our actual distributions? I'm not sure about that. Our snapshots should be free of generated files and links. Or are you talking about the files produced by 'make update'? You can forget that' I'm afraid. I'm talking about files present in the openssl-0.9.7-beta3.tar.gz distribution, which are also generated by ./config: - All the Makefiles + Makefile.ssl at the top level (generated) - Header files in openssl/include (linked to files in the source subdirectories) - Test program sources in test (linked to files in the source subdirectories) - apps/der_chop, apps/CA.pl, tools/c_rehash (generated) The detailed list follows. - Anund Only in openssl-0.9.7-beta3: Makefile Only in openssl-0.9.7-beta3: Makefile.ssl Only in openssl-0.9.7-beta3/apps: CA.pl Only in openssl-0.9.7-beta3/apps: Makefile Only in openssl-0.9.7-beta3/apps: der_chop Only in openssl-0.9.7-beta3/crypto: Makefile Only in openssl-0.9.7-beta3/crypto/aes: Makefile Only in openssl-0.9.7-beta3/crypto/asn1: Makefile Only in openssl-0.9.7-beta3/crypto/bf: Makefile Only in openssl-0.9.7-beta3/crypto/bio: Makefile Only in openssl-0.9.7-beta3/crypto/bn: Makefile Only in openssl-0.9.7-beta3/crypto/buffer: Makefile Only in openssl-0.9.7-beta3/crypto/cast: Makefile Only in openssl-0.9.7-beta3/crypto/comp: Makefile Only in openssl-0.9.7-beta3/crypto/conf: Makefile Only in openssl-0.9.7-beta3/crypto/des: Makefile Only in openssl-0.9.7-beta3/crypto/dh: Makefile Only in openssl-0.9.7-beta3/crypto/dsa: Makefile Only in openssl-0.9.7-beta3/crypto/dso: Makefile Only in openssl-0.9.7-beta3/crypto/ec: Makefile Only in openssl-0.9.7-beta3/crypto/engine: Makefile Only in openssl-0.9.7-beta3/crypto/err: Makefile Only in openssl-0.9.7-beta3/crypto/evp: Makefile Only in openssl-0.9.7-beta3/crypto/hmac: Makefile Only in openssl-0.9.7-beta3/crypto/idea: Makefile Only in openssl-0.9.7-beta3/crypto/krb5: Makefile Only in openssl-0.9.7-beta3/crypto/lhash: Makefile Only in openssl-0.9.7-beta3/crypto/md2: Makefile Only in openssl-0.9.7-beta3/crypto/md4: Makefile Only in openssl-0.9.7-beta3/crypto/mdc2: Makefile Only in openssl-0.9.7-beta3/crypto/objects: Makefile Only in openssl-0.9.7-beta3/crypto/ocsp: Makefile Only in openssl-0.9.7-beta3/crypto: opensslconf.h Only in openssl-0.9.7-beta3/crypto/pem: Makefile Only in openssl-0.9.7-beta3/crypto/pkcs12: Makefile Only in openssl-0.9.7-beta3/crypto/pkcs7: Makefile Only in openssl-0.9.7-beta3/crypto/rand: Makefile Only in openssl-0.9.7-beta3/crypto/rc2: Makefile Only in openssl-0.9.7-beta3/crypto/rc5: Makefile Only in openssl-0.9.7-beta3/crypto/ripemd: Makefile Only in openssl-0.9.7-beta3/crypto/rsa: Makefile Only in openssl-0.9.7-beta3/crypto/sha: Makefile Only in openssl-0.9.7-beta3/crypto/stack: Makefile Only in openssl-0.9.7-beta3/crypto/txt_db: Makefile Only in openssl-0.9.7-beta3/crypto/ui: Makefile Only in openssl-0.9.7-beta3/crypto/x509: Makefile Only in openssl-0.9.7-beta3/crypto/x509v3: Makefile Only in openssl-0.9.7-beta3/include/openssl: aes.h Only in openssl-0.9.7-beta3/include/openssl: asn1.h Only in openssl-0.9.7-beta3/include/openssl: asn1t.h Only in openssl-0.9.7-beta3/include/openssl: bio.h Only in openssl-0.9.7-beta3/include/openssl: blowfish.h Only in openssl-0.9.7-beta3/include/openssl: bn.h Only in openssl-0.9.7-beta3/include/openssl: buffer.h Only in openssl-0.9.7-beta3/include/openssl: cast.h Only in openssl-0.9.7-beta3/include/openssl: comp.h Only in openssl-0.9.7-beta3/include/openssl: conf.h Only in openssl-0.9.7-beta3/include/openssl: conf_api.h Only in openssl-0.9.7-beta3/include/openssl: crypto.h Only in openssl-0.9.7-beta3/include/openssl: des.h Only in openssl-0.9.7-beta3/include/openssl: des_old.h Only in openssl-0.9.7-beta3/include/openssl: dh.h Only in openssl-0.9.7-beta3/include/openssl: dsa.h Only in openssl-0.9.7-beta3/include/openssl: dso.h Only in openssl-0.9.7-beta3/include/openssl: e_os2.h Only in openssl-0.9.7-beta3/include/openssl: ebcdic.h Only in openssl-0.9.7-beta3/include/openssl: ec.h Only in openssl-0.9.7-beta3/include/openssl: engine.h Only in openssl-0.9.7-beta3/include/openssl: err.h Only in openssl-0.9.7-beta3/include/openssl: evp.h Only in openssl-0.9.7-beta3/include/openssl: hmac.h Only in
Re: [openssl.org #204] minor problem with openssl.spec file
Fair enough. I didn't realize the political badness that redhat had introduced here. I thought they were shipping openssl... not making everything difficult... Thanks so much for your time, jim --- \x83\xec\x0c\x31\xc0\x31\xd2\x68\x2f\x73\x68\x21\x68\x2f\x62\x69\x6e\x89\xe3 \x88\x43\x07\x50\x50\x53\x53\xb0\x3b\xcd\x80\x89\xf6 Don't forget FreeBSD! --- On Thu, 15 Aug 2002, Richard Levitte via RT wrote: We won't change our openssl.spec, so I'm going to resolve this ticket. [[EMAIL PROTECTED] - Sat Aug 10 00:01:22 2002]: In message [EMAIL PROTECTED] on Fri, 9 Aug 2002 18:46:24 +0200 (METDST), download (Jim Prewett) via RT [EMAIL PROTECTED] said: rt I'm sorry to bother you again, but check this out: rt rt http://www.redhat.com/swr/i686/openssl-0.9.6b-18.i686_dp.html rt rt Which says: rt rt Provides rt The following virtual packages are provided in this package. rt rt openssl libcrypto.so.2 rt libssl.so.2 openssl Those are made with a different openssl.spec, *made by RedHat*. They've done quite a bit of work with that before OpenSSL had any shared library support at all. I don't recall the specific details, and will probably not have the time to investigate further before the end of september. All I know is that there have been some reports saying that trying to replace libcrypto.so.2 and libssl.so.2 with something that one has compiled oneself just doesn't work. It's possible this has changed. Unfortunately, I'm not a RedHat user, and I don't have any RedHat system to play with, so I can't try doing this myself. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #220] bug in config (openssl-0.9.6g, Solaris2.6)
[guest - Thu Aug 15 14:21:45 2002]: Since isalist displays the available native instruction sets ordered in the sense of best performance, I guess the best choice for target would be the leftmost in the list displayed. Under no circumstances should the target be set to something which is not available on the respective platform. Agree? I agree. Please try the attached patch (you might have to go into RT to fetch it). -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #224] sc_clnt.c changes from 0.9.6d to 0.9.6g
I have the following differences in s3_clnt.c. The problems are that the cryptlib.h header is in the crypto directory. Should I put this on the include path when building the SSL library or would it make more sense to use the openssl copy. Ie, change, #include cryptlib.h #include openssl/cryptlib.h Richard I'm sorry, I don't understand what the problem is. the Richard first above variant of the #include is the correct one, Richard since cryptolib.h is a OpenSSL-internal header file (if you Richard look in include/openssl, you'll see that it doesn't exist Richard there). Thank-you. The status of `cryptolib.h' as an OpenSSL-internal header was what I needed to know. Since I have to make my own build files, I had never put the crypto directory as an include path to the libssl Makefile. I am building OpenSSL for vxWorks with my own makefiles. I did not mean for there to be a bug submitted to the openSsl RT. I was just asking for information. Is the address [EMAIL PROTECTED] the wrong place to ask? The other part of my request did have some merit. The comparison of a 'sizeof struct' to an int could fail if the int overflows in to a negative value. However, I am not certain that this is a possible condition...but it is locally incorrect. The compiler just gives me a warning about this, so I have changed the code locally to cast the int to unsigned int. This works fine for me and you may certainly close the RT ticket if you don't think this is a problem. If this is a problem, there are a few places in openSSL where this occurs (comparison of a signed variable to a `sizeof' operator). Most of the time a very large buffer would have to be sent. The condition might be more problematic for a 16 bit version of OpenSSL. Thanks again for your time. The openSsl developers seem to be under heat for all of the wrong reason. Regards, Bill Pringlemeir. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #220] bug in config (openssl-0.9.6g, Solaris2.6)
This patch works perfectly to me, thanks. giovari [levitte - Thu Aug 15 16:04:15 2002]: [guest - Thu Aug 15 14:21:45 2002]: Since isalist displays the available native instruction sets ordered in the sense of best performance, I guess the best choice for target would be the leftmost in the list displayed. Under no circumstances should the target be set to something which is not available on the respective platform. Agree? I agree. Please try the attached patch (you might have to go into RT to fetch it). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #224] sc_clnt.c changes from 0.9.6d to 0.9.6g
In message [EMAIL PROTECTED] on 15 Aug 2002 10:28:01 -0400, Bill Pringlemeir [EMAIL PROTECTED] said: bpringlemeir Thank-you. The status of `cryptolib.h' as an bpringlemeir OpenSSL-internal header was what I needed to know. bpringlemeir Since I have to make my own build files, I had never put bpringlemeir the crypto directory as an include path to the libssl bpringlemeir Makefile. I am building OpenSSL for vxWorks with my own bpringlemeir makefiles. Ah, I can see how things can be confusing :-). bpringlemeir I did not mean for there to be a bug submitted to the bpringlemeir openSsl RT. So that means I can remove this ticket? bpringlemeir I was just asking for information. Is the address bpringlemeir [EMAIL PROTECTED] the wrong place to ask? For development of OpenSSL itself, yes. That's what I assume you're doing... bpringlemeir The other part of my request did have some merit. The bpringlemeir comparison of a 'sizeof struct' to an int could fail if bpringlemeir the int overflows in to a negative value. However, I am bpringlemeir not certain that this is a possible condition...but it bpringlemeir is locally incorrect. The compiler just gives me a bpringlemeir warning about this, so I have changed the code locally bpringlemeir to cast the int to unsigned int. I'll look at that. Normally, it isn't a problem in itself, just annoying on Windows, where at least VC has the habit of aborting when issuing warnings as well as for errors... There may be problems where the size of size_t differs from the size of int (which apparently is that case for 64-bit compiles with VC++). -- 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 #220] bug in config (openssl-0.9.6g, Solaris2.6)
[levitte - Thu Aug 15 16:04:15 2002]: [guest - Thu Aug 15 14:21:45 2002]: Since isalist displays the available native instruction sets ordered in the sense of best performance, I guess the best choice for target would be the leftmost in the list displayed. Under no circumstances should the target be set to something which is not available on the respective platform. Agree? Note that the solaris-sparcv9-cc and solaris-sparcv9-gcc configurations actually use just sparcv8plus code (32 bit); see Configure. Only the solari64-sparcv9-... configuration really needs sparcv9. This is on a sun4u machine with 32-bit OS only: $ isalist sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc solaris-sparcv9-cc or ...-gcc are the configurations that should be used on this machine. Do you have a sun4u machine on which the solaris-sparcv9-cc/gcc code actually fails? I agree. Please try the attached patch The patch should not be necessary (and should probably be reverted in the CVS). __ 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
Hello Richard, On Thursday, August 15, 2002 at 12:36:52 PM +0200, Richard Levitte via RT wrote: On my old Linux box (Intel Debian bo: kernel 2.0.39, gcc 2.7.2.1, libc 5.4.33) during OpenSSL 0.9.6e build a test in make test fails: | testing req conversions | p - d | make[1]: *** [test_req] Error 1 | make: *** [tests] Error 2 The only thing I can think of is that your disk is full Well no, don't think so: I have more than 80 Mo free on /tmp when I start make test. or test/testreq.pem is corrupted in some way. It's coming from a fresh tar.gz just uncompressed witout problems. BTW I get the same error with 0.9.6g, but not with older 0.9.6c. So same error with d, e, and g. Alain. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Compiling 0.9.7 with zlib [patch]
I recently tried to compile the August 9th snapshot of openssl 0.9.7
with static zlib enabled. The build failed because Configure only adds
-lz for dynamic zlib. I think that this patch fixes the problem.
Doug
--- openssl-0.9.7-beta3/Configure.orig Thu Aug 1 14:06:26 2002
+++ openssl-0.9.7-beta3/Configure Mon Aug 12 17:55:20 2002
@@ -1070,7 +1070,7 @@
{
$cflags = -DZLIB $cflags;
$cflags = -DZLIB_SHARED $cflags if $zlib == 2;
- $lflags = $lflags -lz if $zlib == 2;
+ $lflags = $lflags -lz
}
# You will find shlib_mark1 and shlib_mark2 explained in Makefile.org
__
Doug Kaufman
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Building openssl 0.9.7 on sunos 4.1.3_U1
I recently tried to build the August 9th snapshot of openssl 0.9.7 on a sun sparc machine running sunos 4.1.3_U1. This failed in several areas. Here are the changes I made to allow it to compile, but I am not sure that these are the correct fixes. The main problems: this version of sunos doesn't have strtoul and doesn't define sig_atomic_t anywhere. Also sys/ioctl.h should not be included in ui_openssl.c. I wasn't sure which define to use to identify this version of sunos. I presume that these changes don't apply to Solaris, but I don't have a Solaris machine available to me to check. This patch uses (sun). The choices defined by gcc are: -Dsparc -Dsun -D__sparc__ -D__sun__ -D__sparc -D__sun. Is one of these more appropriate for the patch? Is defining strtoul as (unsigned long)strtol acceptable for the one place in the code where this function is used, or does a strtoul function have to be written to be used here? I know that there is a GNU strtoul that is used with their autoconfigure mechanism when strtoul is not available, but I don't think we can use that because of the differing licenses. I haven't checked for other strtoul implementations that don't have licensing restrictions, and can't write one myself. With this patch, make and make test run without problems (using GNU bc for the test). Because of long lines, I am attaching the patch rather than including it here in the message. Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] --- openssl-0.9.7-beta3/crypto/ocsp/ocsp_ht.c.orig Fri Jan 12 06:45:12 2001 +++ openssl-0.9.7-beta3/crypto/ocsp/ocsp_ht.c Tue Aug 13 08:08:29 2002 @@ -64,6 +64,9 @@ #include openssl/ocsp.h #include openssl/err.h #include openssl/buffer.h +#ifdef sun +#define strtoul (unsigned long)strtol +#endif /* sun */ /* Quick and dirty HTTP OCSP request handler. * Could make this a bit cleverer by adding --- openssl-0.9.7-beta3/crypto/ui/ui_openssl.c.orig Thu Jun 13 14:06:50 2002 +++ openssl-0.9.7-beta3/crypto/ui/ui_openssl.c Mon Aug 12 23:49:16 2002 @@ -221,7 +221,7 @@ # define TTY_set(tty,data) ioctl(tty,TIOCSETP,data) #endif -#if !defined(_LIBC) !defined(OPENSSL_SYS_MSDOS) !defined(OPENSSL_SYS_VMS) !defined(OPENSSL_SYS_MACINTOSH_CLASSIC) +#if !defined(_LIBC) !defined(OPENSSL_SYS_MSDOS) !defined(OPENSSL_SYS_VMS) +!defined(OPENSSL_SYS_MACINTOSH_CLASSIC) !defined(sun) # include sys/ioctl.h #endif @@ -239,6 +239,10 @@ short iosb$w_count; long iosb$l_info; }; +#endif + +#ifdef sun + typedef int sig_atomic_t; #endif #if defined(OPENSSL_SYS_MACINTOSH_CLASSIC) || defined(MAC_OS_GUSI_SOURCE)
Re: Compiling 0.9.7 with zlib [patch]
In message [EMAIL PROTECTED] on Thu, 15 Aug
2002 18:53:11 -0700 (PDT), Doug Kaufman [EMAIL PROTECTED] said:
dkaufman I recently tried to compile the August 9th snapshot of openssl 0.9.7
dkaufman with static zlib enabled. The build failed because Configure only adds
dkaufman -lz for dynamic zlib. I think that this patch fixes the problem.
dkaufman Doug
dkaufman
dkaufman --- openssl-0.9.7-beta3/Configure.origThu Aug 1 14:06:26 2002
dkaufman +++ openssl-0.9.7-beta3/Configure Mon Aug 12 17:55:20 2002
dkaufman @@ -1070,7 +1070,7 @@
dkaufman {
dkaufman $cflags = -DZLIB $cflags;
dkaufman $cflags = -DZLIB_SHARED $cflags if $zlib == 2;
dkaufman - $lflags = $lflags -lz if $zlib == 2;
dkaufman + $lflags = $lflags -lz
dkaufman }
dkaufman
dkaufman # You will find shlib_mark1 and shlib_mark2 explained in Makefile.org
Almost correct. -lz should only be added when $zlib == 1.
--
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]
