Re: [OT] "library has no ciphers"
Christopher P. Masone, 2005-11-02: > > So, I've recently upgraded to 0.9.8a. Before this, I was using 0.9.7h, and > things were working fine. > > Now, I'm getting a "library has no ciphers" error the first time I call > SSL_CTX_new...despite the fact that I have called OpenSSL_add_all_algorithms() > before I try to do any SSL stuff. I changed it to a pair of calls, one to > OpenSSL_add_all_ciphers() and one to OpenSSL_add_all_digests() to see if I > could > get a better handle on what's happening, and it seems that whichever of those > two that I call second "sticks". > > This didn't used to happen with the older version of the library. I need to > use > 0.9.8 for other features...can anyone tell me what's going on and how to fix > it? I had a similar problem with MySQL while upgrading to 0.9.8a. In the end, it was just a matter of calling SSL_library_init() early, at database startup time. Leandro __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: "library has no ciphers"
--- Christopher P. Masone wrote: So, I've recently upgraded to 0.9.8a. Before this, I was using 0.9.7h, and things were working fine. Now, I'm getting a "library has no ciphers" error the first time I call SSL_CTX_new...despite the fact that I have called OpenSSL_add_all_algorithms() before I try to do any SSL stuff. I changed it to a pair of calls, one to OpenSSL_add_all_ciphers() and one to OpenSSL_add_all_digests() to see if I could get a better handle on what's happening, and it seems that whichever of those two that I call second "sticks". This didn't used to happen with the older version of the library. I need to use 0.9.8 for other features...can anyone tell me what's going on and how to fix it? Thanks, Chris --- end of quote --- Ooops...egg on my face. It seems that it's just that OpenSSL_add_all_ciphers() doesn't work. Which seems strange. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
"library has no ciphers"
So, I've recently upgraded to 0.9.8a. Before this, I was using 0.9.7h, and things were working fine. Now, I'm getting a "library has no ciphers" error the first time I call SSL_CTX_new...despite the fact that I have called OpenSSL_add_all_algorithms() before I try to do any SSL stuff. I changed it to a pair of calls, one to OpenSSL_add_all_ciphers() and one to OpenSSL_add_all_digests() to see if I could get a better handle on what's happening, and it seems that whichever of those two that I call second "sticks". This didn't used to happen with the older version of the library. I need to use 0.9.8 for other features...can anyone tell me what's going on and how to fix it? Thanks, Chris __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Small thing in apps/speed.c
Johan Gill wrote: This patch just moves an ifdef so sstrsep() doesn't get compiled if HAVE_FORK isn't defined. thanks, applied. Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[PATCH] Small thing in apps/speed.c
This patch just moves an ifdef so sstrsep() doesn't get compiled if HAVE_FORK isn't defined. -- Johan Gill, [EMAIL PROTECTED] Index: apps/speed.c === RCS file: /home/johane/openssl/cvs/openssl/apps/speed.c,v retrieving revision 1.129 diff -u -r1.129 speed.c --- apps/speed.c16 Jul 2005 12:37:28 - 1.129 +++ apps/speed.c2 Nov 2005 14:43:11 - @@ -2522,6 +2522,7 @@ results[alg][run_no]=((double)count)/time_used*lengths[run_no]; } +#ifdef HAVE_FORK static char *sstrsep(char **string, const char *delim) { char isdelim[256]; @@ -2553,7 +2554,6 @@ return token; } -#ifdef HAVE_FORK static int do_multi(int multi) { int n;
RE: Problem using Broadcom uBSec engine in 0.9.8
That solves the problem! I was missing the second "LOAD" command, to the OpenSSL stub, telling it where to find the Broadcom library. Thanks! -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 8:54 PM To: openssl-dev@openssl.org Cc: Martin Del Vecchio Subject: Re: Problem using Broadcom uBSec engine in 0.9.8 Hi Martin, Comments inline. On October 28, 2005 09:54 am, Martin Del Vecchio wrote: > Yes, there are two different libubsec.so libraries: > > 1) The one built in OpenSSL with "./config shared"; this > is the stub library that contains "bind_engine", etc. > > 2) The one provided by the Broadcom SDK; this is the actual > library that contains "ubsec_bits_to_bytes", etc. > > If I put 1) in the "right" place (/usr/local/ssl/lib/engines), then > ENGINE_by_id ("ubsec") succeeds. If I remove it from that directory, > then ENGINE_by_id ("ubsec") fails. > > So I put 1) in the "right" place. Then I load the "dynamic" engine: > >Engine = ENGINE_by_id ("dynamic"); > > and give it the following commands: > >Return = ENGINE_ctrl_cmd_string (Engine, "SO_PATH", "ubsec", 0); >Return = ENGINE_ctrl_cmd_string (Engine, "LOAD", NULL, 0); These three steps are essentially what 'ENGINE_by_id("ubsec")' does. The result is that 'Engine' is now the "ubsec" engine and no longer the (or rather a copy of the) "dynamic" engine. > Both succeed; it find the library in in /usr/local/ssl/lib/engines/, > which is the OpenSSL stub. But when I run: > >Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); > > It fails, because it can't find the "ubsec_bits_to_bytes" symbol. Yup, ENGINE_set_default() will try to initialise the engine - if it isn't already initialised - before setting it as a default implementation. Loading the broadcom library is delayed until the initialisation step to ensure you can always get a "structural" reference to an engine, whether or not you have the corresponding hardware, drivers, [etc]. Eg. it's what allows you see the ctrl-commands available for engines even if you can't initialise them as yet; 'apps/openssl engine -' > So > it smells like it wants the Broadcom library in the "LOAD" command, so > I change that to: > >Return = ENGINE_ctrl_cmd_string (Engine, "SO_PATH", > "/usr/lib/libubsec.so", 0); > > Which is where the Broadcom library is. Now the "LOAD" command fails, > because it can't find the "bind_engine" symbol. So now it's looking > for the OpenSSL stub library there! So then I renamed the Broadcom > library to /usr/lib/bc.libubsec.so, and said: > >Return = ENGINE_ctrl_cmd_string (Engine, "SO_PATH", > "/usr/lib/bc.libubsec.so", 0); > > And I got the same error. Did you do this as a replacement for the earlier "SO_PATH" step (ie. prior to the "LOAD")? Until you run the "LOAD" command, 'Engine' is the "dynamic" engine. Once you've called "LOAD", 'Engine' is the loaded "ubsec" engine. At this point, the "SO_PATH" ctrl-command is the one implemented by the "ubsec" engine and not that of the "dynamic" engine, ie. it refers to the broadcom library and not the engine library, but that's only *after* the "LOAD". I think this is probably what you're missing - let me know if I've misunderstood. So, you probably want; #ifdef DO_IT_THE_LONG_WAY /* SO_PATH points the "dynamic" engine to the ubsec engine */ Engine = ENGINE_by_id ("dynamic"); Return = ENGINE_ctrl_cmd_string (Engine, "SO_PATH", "ubsec", 0); /* LOAD changes 'Engine' to be a "ubsec" engine handle */ Return = ENGINE_ctrl_cmd_string (Engine, "LOAD", NULL, 0); #else /* This achieves the same thing as above, if the library has the * appropriate file-name and path. */ Engine = ENGINE_by_id ("ubsec"); #endif /* SO_PATH points the "ubsec" engine to the broadcom library */ Return = ENGINE_ctrl_cmd_string (Engine, "SO_PATH", "bc.libubsec.so", 0); /* This implicitly initialises the engine */ Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1235] Error in running make command.
On Wednesday November 2nd 2005 Bidya Bhusan Hota wrote: > While running the make command for OpenSSL, Im getting an error; ar: command > not found. The error report is as shown below: > > ar r ../libcrypto.a cryptlib.o mem.o mem_clr.o mem_dbg.o cversion.o > ex_data.o t > mdiff.o cpt_err.o ebcdic.o uid.o o_time.o o_str.o > make[1]: ar: Command not found There's your error: it cannot find the 'ar' program. This is normally included on most Unix systems in the 'binutils' package. Perhaps you need to install this package, or make sure that the executable is in your PATH. -- Marco Roeland __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1235] Error in running make command.
Hi, While running the make command for OpenSSL, Im getting an error; ar: command not found. The error report is as shown below: ar r ../libcrypto.a cryptlib.o mem.o mem_clr.o mem_dbg.o cversion.o ex_data.o t mdiff.o cpt_err.o ebcdic.o uid.o o_time.o o_str.o make[1]: ar: Command not found make[1]: *** [lib] Error 127 make[1]: Leaving directory `/home/pb8809/openssl-0.9.7i/crypto' make: *** [sub_all] Error 1 Could anyone please tell, what's the reason for this error. Thanks, Bidya - Yahoo! FareChase - Search multiple travel sites in one click. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]