Hey Alexander,
It appears from your posts that you are a very knowledgeable coder who knows how to improve and increase the performance, stability, and security of the PHP program. I think your input could be very valuable.
I think there would be a more, let's say, graceful, way of giving your input. I know that it's hard to interpret (and easy to misinterpret) attitudes from reading plain text, but here is what I see:
*It seems* that the intro to your code patches have somewhat of a superior attitude. While they may be great patches, you have to remember that real people busted their rear ends to write the code in the first place, and probably got no money for it to boot.
Also, you have many people on this list like Derick that really do and have spent countless hours of time making PHP into what it is. They are the ones that are in charge of what get's included into this great language. They are constantly working their tails off to fix the latest bug, or implement the a new requested feature, or meet the deadline to roll the next RC.
I would say that the priority on developing PHP is: 1. Bug Fixes from bugs.php.net 2. Features that are slated for upcoming versions of PHP 3. Recoding old functions to make them faster and more stable where needed.
If you want your input to be accepted, you got to play the way the rest of the crowd is, in order for it to work.
Thanks for your effort, and I hope you direct it to where it can be used to the fullest.
Sincerely,
Jason Garber President IonZoft, Inc.
At 6/15/2004 06:30 PM +0300, you wrote:
On Tue, 15 Jun 2004 12:47:29 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]> wrote:
On Tue, 15 Jun 2004, Alexander Valyalkin wrote:
Today I checked file /win32/readdir.c Below you can view its source with my comments.
Just a little notice that you succesfully made it into my killfilter. Great job!
Derick
And what about your job? So, you are author of mcrypt module. Let audit your work: /ext/mcrypt/mcrypt.c
Can you explain me the sense of the memset() after any memory allocation in the mcrypt.c. For example: =========================== /* missing type casting from (void *) to (unsigned char *) */ pointer = emalloc (length_of_data); /* sense of the next string? wasting time? */ memset (pointer, 0, length_of_data); memcpy (pointer, data_pointer, length_of_data); ===========================
Why you don't wipe keys and initialization vectors before freeing memory? Leave it for spies from NSA and KGB ? :) For example: =========================== if (key_s != NULL) efree (key_s); if (iv_s != NULL) efree (iv_s); ===========================
Can you explain me the sense of initialization vector [iv] for ECB mode? : =========================== /* {{{ proto string mcrypt_ecb(int cipher, string key, string data, int mode, string iv) ECB crypt/decrypt data using key key with cipher cipher starting with iv */ ===========================
Well, let see documentation of Mcrypt http://php.net/mcrypt/ : ============================== MCRYPT_MODE_OFB (output feedback, in 8bit) is comparable to CFB, but can be used in applications where error propagation cannot be tolerated. It's insecure (because it operates in 8bit mode) so it is not recommended to use it. ==============================
1) What happens with error propagation after deleting/inserting any data into encrypted in OFB-mode text? Do you know what means "self-synchronizing" words for CFB mode?
2) Do you know that not only 8bit OFB is insecure? OFB mode always have less security if size of encrypted text is not equal to blocksize of used cypher. For example, the security of 256bit AES cypher in 255bit mode is the same as for 256bit AES in 8bit OFB mode.
============================== MCRYPT_MODE_CFB (cipher feedback) is the best mode for encrypting byte streams where single bytes must be encrypted. ============================== How can I use this mode for encrypting byte streams, if function mcrypt_cfb() dont return current [iv] value? The same question for other modes, excepting ECB.
-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
