Dude.

You need to brush up a bit on the inter-personal skills. Starting a
flame-war or dick-waving contest on this list is probably not the best
way to get your patches accepted.

George

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 derick@php.net
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/