Re: openssl_(en|de)crypt missing IV

On Tue, May 18, 2010 at 11:37 PM, Sara Golemon <pollita@php.net> wrote: >>> The only BC break is the warning raised when using openssl_encrypt() >>> without >>> an IV.  Given the extremely bad practice using a NULL IV represents, I >>> think >>> this is a reasonable course of action. >> >> It changes the signature making the fifth argument a complete >> different thing. I strongly disagree with this strategy, even if I can >> understand your reasoning. We can't begin to "fix" things by changing >> existing API signatures, that's going to end badly. >> > What do you mean by "making the fifth argument a complete different thing"? >  Different to what? The current signature only has four arguments.  This > adds an optional argument which, by itself, is not BC breaking. I misread this paragraph, I kept in mind what you said in your initial post: >> P.S. - Here's the signature I'd go with: openssl_encrypt($data, $method, $iv, >> $key, $raw=false) So yes, putting it at fifth optional argument can work as it won't change the behavior either. >> To define a new and clean API is not only BC but may also allow >> obvious naming. And last but not least, it can then be merged in 5.3 >> without worrying about any possible impact. >> > Absolutely true, and /possibly/ worth the "wtf" that comes with having two > essentially identical functions.  How would you feel about the trunk > versions of the old functions (but not the 5.3 versions) gaining > ZEND_ACC_DEPRECATED in that case? Having new cleaner APIs is what I would prefer to do (in general). And we can indeed add the deprecated flag to 5.3 as well. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org