Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL - possible bug???)
Most definitely not. ... Yes you are right. To qualify what I want to do: openssl does a lot of sharing and locking. I would like to use the minimum by have one context per thread. I use my own session cache so there 'should' not need to be anything else that needs sharing. Further, I use my own BIO buffers and rand object. So in my app, openssl does not go to the operating system for anything. Can you please give me some hints what I should look at changing in openssl to do this? Paul Sent via my BlackBerry from Vodacom - let your email find you! -Original Message- From: David Schwartz [EMAIL PROTECTED] Date: Sun, 20 Jan 2008 11:59:00 To:openssl-dev@openssl.org Subject: RE: Static global - bug? (Re: Two valgrind warnings in OpenSSL - possible bug???) I should be able to create a multithreaded application using a non-multithreaded openssl build provided that I have an ssl context per thread. Most definitely not. At a minimum, the definition of things like 'errno' and 'malloc' might be different between a multithreaded build and a non-multithreaded build. There is no supported way to combine multithreaded code and code that was not compiled to be multithreaded. It may happen to work, but that's a lousy way to make security-sensitive software. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] :§IÏ®ÞrØm¶ÿà (¥éì²Z+7¯zZ)éí1¨¥x Ëh¥éì²W^¾^Ë%¢¸ ºÚj×.+-1©Úêæj:+v¨¢§²Éh®
RE: Static global - bug? (Re: Two valgrind warnings in OpenSSL - possible bug???)
On Sun, 2008-01-20 at 11:59 -0800, David Schwartz wrote: I should be able to create a multithreaded application using a non-multithreaded openssl build provided that I have an ssl context per thread. Most definitely not. At a minimum, the definition of things like 'errno' and 'malloc' might be different between a multithreaded build and a non-multithreaded build. There is no supported way to combine multithreaded code and code that was not compiled to be multithreaded. It may happen to work, but that's a lousy way to make security-sensitive software. Definitely not true on gcc+glibc - there is no difference between multithreaded and non-multithreaded _compilation_ (surely not for errno and malloc). So it is pretty safe to use non-multithreaded libraries (if they are reentrant) in multithreaded applications on gcc+glibc. Of course at link time and especially run time, the code being executed in glibc is very different. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Possible bug in in x509v3_config manpage
Hi, the x509v3_config manpage tells me The name constraints extension is a multi-valued extension. The name should begin with the word permitted or excluded followed by a ;. The rest of the name and the value follows the syntax of subjectAltName except email:copy is not supported and the IP form should consist of an IP addresses and subnet mask separated by a /. From what I understand, nameConstraints is only used for CAs and defines what ranges this CA may or may not sign for. If I am mistaken, please disregard this email. If I am not mistaken, it would probably good to adapt the manpage to be clearer. Thanks, Richard __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL - possible bug???)
On Mon, Jan 21, 2008 at 09:24:34AM +0100, Tomas Mraz wrote: On Sun, 2008-01-20 at 11:59 -0800, David Schwartz wrote: I should be able to create a multithreaded application using a non-multithreaded openssl build provided that I have an ssl context per thread. Most definitely not. At a minimum, the definition of things like 'errno' and 'malloc' might be different between a multithreaded build and a non-multithreaded build. There is no supported way to combine multithreaded code and code that was not compiled to be multithreaded. It may happen to work, but that's a lousy way to make security-sensitive software. Definitely not true on gcc+glibc - there is no difference between multithreaded and non-multithreaded _compilation_ (surely not for errno and malloc). In Debian we have a policy of compiling all libraries with -D_REENTRANT. As far as I know this was needed for LinuxThreads support. I'm not sure it's still needed since we switch to NPTL. There was a time when -D_REENTRANT had some effects, I'm not sure it still does. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
On Sun, 2008-01-20 at 11:59 -0800, David Schwartz wrote: Most definitely not. At a minimum, the definition of things like 'errno' and 'malloc' might be different between a multithreaded build and a non-multithreaded build. There is no supported way to combine multithreaded code and code that was not compiled to be multithreaded. It may happen to work, but that's a lousy way to make security-sensitive software. Definitely not true on gcc+glibc Umm, definitely true. - there is no difference between multithreaded and non-multithreaded _compilation_ (surely not for errno and malloc). Really? So 'errno' refers to a process global in both cases?! (Note that I said the definition, not the implementation.) So it is pretty safe to use non-multithreaded libraries (if they are reentrant) in multithreaded applications on gcc+glibc. Of course at link time and especially run time, the code being executed in glibc is very different. The problem is that it is neither specified to work nor guarantee to work. You may enjoy writing security-sensitive software that just happens to work where you have to retest your assumptions with every new version of the system libraries, but I don't. I hope you don't dynamically-link such a thing. You have no way of knowing if the glibc libraries you might happen to run-time link to will work. When you use features that aren't guaranteed, a newer version may break the assumptions and still claim compatability. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
