No, no one has fixed SSL (or modules it depends on) because no one knew there was any problem with it.
"Cannot be used immediately afetr installation" == "Doesn't work properly", or you think different? :)
Danger. Logic. Dragons rest here... I guess you really mean
There is someone who can not use SSL immediately after installing Pike -> SSL doesn't work properly.
The statement is easy to prove wrong. (black out, broken hard drive, wrong installation procedure, bug in Pike core)
Now, why am I being an ass about this? Experience has show that the implication "I can't get X to work" -> "X is broken" doesn't hold nearly as often as one wants. Most often it is Q that is broken or that the I did something wrong. This is the developers forum, so helping the I to do right is off topic while looking past X and finding Q is on topic. We can however not do that without your help.
Anyway, the point you initially wanted to make was that OpenSSL is better since you can not get Pikes SSL module to work. That point is moot since there is no guarantee that an OpenSSL module would work more often.
/ Martin Nilsson (Åskblod)
Previous text:
2003-01-28 18:54: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
On Tue, Jan 28, 2003 at 06:15:01PM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum wrote:
As you can see in the backtrace, it isn't the SSL module but the
Look at this:
Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/handshake.pike:978:Failed to index module 'X509' with 'decode_certificate' (module doesn't exist?)
It is not Calendar, but anyway, SSL and Tools.X509 are dependent (somehow) on Caldendar... :) But in this case reference is to X509 which is actually in Tools.X509 (it was fixed later on but brokem again).
Anyway, I cannot use SSL.* after compilation/installation without tweaking.
"Cannot be used immediately afetr installation" == "Doesn't work properly", or you think different? :)
Regards, /Al
/ Brevbäraren