Not to mention that people working on OpenSSL have experience in crypto related areas, while this is not main focus of Pike team.
Problem is, to write secure crypto code in C you need to *both* understand security and cryptography, and be a good C programmer. Judging from the original ssleay code, Eric Young was a knowledgable crypto guy and a poor C programmer (his x86 DES on the other hand was probably pretty good, but I don't read x86 assembler so I can't really tell). His code is *slowly* being replaced by the current openssl hackers, but they still have a lot of old junk left.
Sorry to say, but I don't completely trust in crypto stuff which is not implemented by someone who has a track in this area already - the IT security is my business, I performed several security projects so I know what I am talking about. To read the spec and to implement it is often not enough.
I don't think I want to get into that discussion. Sure, I have a lot more experience now than I had back when I wrote roxen's SSL code years ago. And I don't know much about its development since I left.
Sure, the lower language is - the greater the chance of mistakes. For newbies. But not for someone who knows what he is doing. Is Pike language for beginners?
It's easy to make mistakes. There were a couple of exploitable buffer overruns on openssl recently, right? Buffer overruns have been known for 20 years. People who know what they're doing simply won't make that simple mistake, right? Still the bug crept into openssl.
Sure, there's a lot more buffer overruns etc in crappy software written by people who don't understand or care about security (say, wuftpd), but the bugs easily creep into any big program written in C, even if written by people who *know* what they're doing. Like openssl, which is *huge*.
a good idea. Implementing SSL in C is probably a bad idea.
No difference.
And this *is* a problem with C. Higher level languages simply doesn't have that problem. Sure, there may be security bugs also in roxen, but I trust my code more than openssl, not because I'm smarter than the openssl folks (I don't even know all of them), but because I haven't inherited a *huge* code base written by Eric Young. The Pike SSL code is one or two orders of magnitude smaller. I'd be more worried about buffer overruns in the pike interpreter itself (which *is* written in C), or in the crypto modules which are written in C, than in the SSL code.
/ Niels Möller ()
Previous text:
2003-01-28 09:06: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
On Tue, Jan 28, 2003 at 01:50:01AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum wrote:
Well, I've got a nicely working SSL in Pike 7.4.10 and 7.4.15 here, so it sounds to me that you are doing something wrong.
The only thing what I a doing wrong is that I run "make sure" after compilation of Pike, and see a lot of in SSL stuff. Well:
--- snip --- Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
object sc = SSL.connection(0);
/usr/local/pike/7.4.10/lib/modules/Calendar.pmod/ISO.pmod:16:Couldn't index module 'Gregorian'. /usr/local/pike/7.4.10/lib/modules/Calendar.pmod/Stardate.pmod:313:Undefined identifier TimeofDay. /usr/local/pike/7.4.10/lib/modules/Calendar.pmod/Stardate.pmod:313:Illegal program identifier (type: int). /usr/local/pike/7.4.10/lib/modules/Calendar.pmod/ISO.pmod:16:Placeholder already has storage! /${PIKE_MODULE_PATH}/Calendar.pmod.Stardate.pmod:-: Warning: Compilation failed: Compilation failed. [... lot of backtrace skipped ...] Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/handshake.pike:978:Failed to index module 'X509' with 'decode_certificate' (module doesn't exist?) Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:26:Error finding program Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:26:Illegal program pointer. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:35:Illegal program pointer. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:36:Illegal program pointer. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:37:Illegal program pointer. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:41:No inherit or surrounding class alert. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:42:No inherit or surrounding class urgent. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:43:No inherit or surrounding class application. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:46:No inherit or surrounding class handshake. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:123:No inherit or surrounding class alert. Compiler Error: /${PIKE_MODULE_PATH}/SSL.pmod/connection.pike:126:No inherit or surrounding class urgent. Compiler Error: 1:Index 'connection' not present in module 'SSL'. --- snip ---
Perhaps I do something wrong, but then "make sure" also does something wrong, but usually I trust tests... Should I don't anymore? :)
You can begin with explaining what you mean with "unresolved references" since that is not an error usually mentioned when discussing Pike problems.
It is an error, since I can't use some modules because it references something which doesn't exists. I am wrong?
I want facts, features, figures or I'll disregard from all these arguments except the speed one, which I have already seen measurements and charts for.
Ciphers - RC2/RC4/RC5/Blowfish/Idea/Cast, with all possible modes of operation. Tell me please where Blowfish or RC5 in Pike is?
Concerning API - I'll make detailed comparision later. Line-by-line.
Not to mention that people working on OpenSSL have experience in crypto related areas, while this is not main focus of Pike team. Sorry to say, but I don't completely trust in crypto stuff which is not implemented by someone who has a track in this area already - the IT security is my business, I performed several security projects so I know what I am talking about. To read the spec and to implement it is often not enough.
footprint, but at the same time greater portability problems and easier to make harmful bugs.
Sure, the lower language is - the greater the chance of mistakes. For newbies. But not for someone who knows what he is doing. Is Pike language for beginners?
a good idea. Implementing SSL in C is probably a bad idea.
No difference. Especially because there are several good and stable implementations around. Yes, yes, I know there was no one (or almost no one) long time ago, but we are living _now_ :) Very similar to PCRE stuff - the best (around) implementation of RE is not included in Pike...
outperformed C code in several benchmarks because the naive implementation in Pike (which utilizes optimized algorithms deeper down) is faster than the naive implementation in C.
I would like to see how to implement circular list in Pike (pure Pike) and achieve good performance... Comparable to, at least, with Perl.
ADT.List is bad example - lists are implemented with help of arrays, while arrays are getting slow in Pike. Though this is transparent for end-user, it is quite ineffective (I already posted my thoughts about arrays).
And... There is _no way_ to outperform native C implementation, since Pike by itself is implemented in C. Some bad implementation in C would be worse than good (by algorithms) in Pike, but that is all.
Regards, /Al
/ Brevbäraren