On Tue, May 18, 2010 at 11:17 PM, Sara Golemon <poll...@php.net> wrote: >>> Fixing this is a simple matter, but I wanted to bounce approaches for BC >>> (or >>> lack thereof) off everyone else since this version of openssl_encrypt() >>> is >>> already "in the wild". >> >>> I think it's worth a BC break. Comments? >> >> To break BC is a no go, even if your arguments are appealing (even in >> a major version). >> > > I disagree about it's no-go-ness, given the fact that these functions aren't > particularly usable as-is, but it's also not worth a fight. > > Given the comments made on list my intentions are as follows: > > 1) Add $iv as a fifth, optional parameter to openssl_(en|de)crypt() > 2) Throw a warning if openssl_encrypt() is used without an IV > 3) Add openssl_cipher_get_iv_length($cipher) > > I intend to make these changes on both trunk and PHP_5_3 because, IMO, this > is a bug, not merely a missing feature. > > 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. 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. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
