[no subject]
Hi Richard, Thanks for taking a look at this. [guest - Thu Oct 6 11:55:10 2005]: This stops our engine working with the openssl application (as it registers a lock debugging callback) and Apache 2.x (and other apps too no doubt) That's because those applications don't set up callbacks for the dynamic locks. The correct thing to do is to talk with the application authors and tell them that there are new requirements to make engines work. Unfortunately we do not have relationships with all of the application developers for the applications that our customers use, so this is not possible. We shall certainly apply pressure in this direction where we can. On that note, is there a plan to update the apps/openssl application to not use the static lock callback for lock debugging? or is there something else that we could do instead to allow our engine to work with static locks? It seems that the dynamic locks are rarely used. Yes, it's true, they are rarely use... currently. However, I really would encourage people to use them more, as they are a bit more flexible than the static locks. Ideally, OpenSSL should probably move to dynamic locks entirely, which would make maintainance quite a bit easier. The dynamic locks are clearly a much better solution and removing them from openssl will force all applications to move , which would be a good thing in the long run. Is there a plan to do this for any specific future release? Why is it that the static locks have not been removed completely for 0.9.8? If it is to keep some backward compatibility with older apps, or ones that see no reason to change, would it not be preferable if the whole of openssl was compatible in this way, including the engines? It seems a bit unfair on the end users who need hardware support for openssl to keep the interface, so the apps don't realise that they need to change, but to remove the engine support from these apps. I appreciate that the hack for our static lock was not pleasant, but it is no less pleasant than all the other static locks. Are you sure we can't persuade you to put it back in until all static locks are removed? By the way, do you have an nCipher HSM for interop testing? Thanks again -john -- John Hartley nCipher Ltd http://www.ncipher.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1212] chil engine no longer works with static locks in 0.9.8
[Originally sent by John, all I'm doing is forwarding it to our ticket database to make sure it gets included. -- Richard Levitte] Hi Richard, Thanks for taking a look at this. [guest - Thu Oct 6 11:55:10 2005]: This stops our engine working with the openssl application (as it registers a lock debugging callback) and Apache 2.x (and other apps too no doubt) That's because those applications don't set up callbacks for the dynamic locks. The correct thing to do is to talk with the application authors and tell them that there are new requirements to make engines work. Unfortunately we do not have relationships with all of the application developers for the applications that our customers use, so this is not possible. We shall certainly apply pressure in this direction where we can. On that note, is there a plan to update the apps/openssl application to not use the static lock callback for lock debugging? or is there something else that we could do instead to allow our engine to work with static locks? It seems that the dynamic locks are rarely used. Yes, it's true, they are rarely use... currently. However, I really would encourage people to use them more, as they are a bit more flexible than the static locks. Ideally, OpenSSL should probably move to dynamic locks entirely, which would make maintainance quite a bit easier. The dynamic locks are clearly a much better solution and removing them from openssl will force all applications to move , which would be a good thing in the long run. Is there a plan to do this for any specific future release? Why is it that the static locks have not been removed completely for 0.9.8? If it is to keep some backward compatibility with older apps, or ones that see no reason to change, would it not be preferable if the whole of openssl was compatible in this way, including the engines? It seems a bit unfair on the end users who need hardware support for openssl to keep the interface, so the apps don't realise that they need to change, but to remove the engine support from these apps. I appreciate that the hack for our static lock was not pleasant, but it is no less pleasant than all the other static locks. Are you sure we can't persuade you to put it back in until all static locks are removed? By the way, do you have an nCipher HSM for interop testing? Thanks again -john -- John Hartley nCipher Ltd http://www.ncipher.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1212] chil engine no longer works with static locks in 0.9.8
[Originally sent by John, all I'm doing is forwarding it to our ticket database to make sure it gets included. -- Richard Levitte] [And I did it wrong the first time. Appologies for the dupliactes] Hi Richard, Thanks for taking a look at this. [guest - Thu Oct 6 11:55:10 2005]: This stops our engine working with the openssl application (as it registers a lock debugging callback) and Apache 2.x (and other apps too no doubt) That's because those applications don't set up callbacks for the dynamic locks. The correct thing to do is to talk with the application authors and tell them that there are new requirements to make engines work. Unfortunately we do not have relationships with all of the application developers for the applications that our customers use, so this is not possible. We shall certainly apply pressure in this direction where we can. On that note, is there a plan to update the apps/openssl application to not use the static lock callback for lock debugging? or is there something else that we could do instead to allow our engine to work with static locks? It seems that the dynamic locks are rarely used. Yes, it's true, they are rarely use... currently. However, I really would encourage people to use them more, as they are a bit more flexible than the static locks. Ideally, OpenSSL should probably move to dynamic locks entirely, which would make maintainance quite a bit easier. The dynamic locks are clearly a much better solution and removing them from openssl will force all applications to move , which would be a good thing in the long run. Is there a plan to do this for any specific future release? Why is it that the static locks have not been removed completely for 0.9.8? If it is to keep some backward compatibility with older apps, or ones that see no reason to change, would it not be preferable if the whole of openssl was compatible in this way, including the engines? It seems a bit unfair on the end users who need hardware support for openssl to keep the interface, so the apps don't realise that they need to change, but to remove the engine support from these apps. I appreciate that the hack for our static lock was not pleasant, but it is no less pleasant than all the other static locks. Are you sure we can't persuade you to put it back in until all static locks are removed? By the way, do you have an nCipher HSM for interop testing? Thanks again -john -- John Hartley nCipher Ltd http://www.ncipher.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1212] chil engine no longer works with static locks in 0.9.8
In message [EMAIL PROTECTED] on Thu, 03 Nov 2005 12:32:30 +0100 (CET), Richard Levitte - VMS Whacker [EMAIL PROTECTED] said: richard [Originally sent by John, all I'm doing is forwarding it to our ticket richard database to make sure it gets included. -- Richard Levitte] I did it wrong. Sorry for this extra duplicate... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ 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 you _must_ call SSL_library_init before you use the SSL stuff 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. the old ssl library initialization was not 100% mt safe so it has been changed. Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
