Re: [PHP-DEV] Asking for a review of crypt() allocation changes
On 29/06/12 14:43, Nikita Popov wrote:
Hi internals!
Anthony and me have been looking a lot at the crypt() code recently
and noticed that there are some strange things going on in the buffer
allocations for the sha algorithms.
We did two commits to fix them up a bit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=7e8276ca68fc622124d51d18e4f7b5cde3536de4
It took me a while to realise the problem being fixed. The bug is not
the memset (as reported in bug 62443),
which is using needed (got fixed in e6cf7d), or php_sha{256,512}_crypt_r
(uses a null-terminated string), but the salt[salt_in_len] = '\0';
after allocating only strlen(salt).
So that you would be accessing the position PHP_MAX_SALT_LEN of the
array but have reserved only a few bytes.
Just*sizeof*(sha512_rounds_prefix
http://lxr.php.net/xref/PHP_TRUNK/ext/standard/crypt.c#sha512_rounds_prefix)
+ 9 + 1 seem enough for not making bug62443.phpt segfault.
I have been able to crash it with var_dump( crypt(foo, '$6$'.chr(0).
str_pad('', 500, '*') . '$abc') );
but only if it's the first call.
Re: [PHP-DEV] concatenation operator
By initialization i mean the latest point possible where I can set a breakpoint, but right before my scripts starts executing it's emalloc's or efree's. but even then you will see many things you're probably not interested in such as?.. Only thing that helps is learning the code structure and digging through it. Any hint/documentation to learn that? Thanks. From: Johannes Schlüter johan...@schlueters.de To: Adi Mutu adi_mut...@yahoo.com Cc: Felipe Pena felipe...@gmail.com; PHP Developers Mailing List internals@lists.php.net Sent: Saturday, June 30, 2012 12:36 AM Subject: Re: [PHP-DEV] concatenation operator On Fri, 2012-06-29 at 11:47 -0700, Adi Mutu wrote: Sorry for the late reply, I was away for a while.. I don't think I have dtrace because I'm on fedora.but i'll research. As said: Currently only on Solaris, MacOS and BSD. Oracle is porting DTrace to Oracle Linux. RedHat created SystemTap which is similar, ut I have never used it. If i would want to set a breakpoint after php's initialization process, but right before the scripts execution, so that after that I can set breakpoints to emalloc and efree which are executed only during my scripts execution where should i set it? Hope the question was clear enough. Depends on your view what initialization is. But execute() might be a place which helps ... but even then you will see many things you're probably not interested in. Only thing that helps is learning the code structure and digging through it. dtrace related: Why have you used 'execute:return' and not concat_function:return? What's with the execute function? That was a bug since I quickly edited an older script. In this case it doesn't change the result. johannes
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
Uhm... = On Fri, Jun 29, 2012 at 6:09 PM, Paul Dragoonis dragoo...@gmail.com wrote: My input is that we should be focusing on features that PHP lacks, or fixing bugs rather than adding more sugar syntax just for the sake of adding it. On Fri, Jun 29, 2012 at 7:47 PM, Pierrick Charron pierr...@webstart.frwrote: No problem when you'll come in Montreal ! If you need any help don't hesitate. Pierrick On 29 June 2012 14:27, Amaury Bouchard ama...@amaury.net wrote: Yes, guys. I totally understand your point. As I said, I had this idea in a dreamed context (good or bad dream? I don't know). But still, I think it's intellectually interesting, even if it's not a good concept for PHP. :-) Pierrick, I owe you a beer ;-) Le 29 juin 2012 19:06, Pierrick Charron pierr...@webstart.fr a écrit : -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] JSON changes in 5.3/5.4
Hi! I see that there were significant changes committed to JSON extension in 5.3 and 5.4 recently. These changes modify json_encode behavior, break tests (pass001.1_64bit.phpt does not work anymore for me), are not clearly documented and have no NEWS/UPGRADING entries describing what exactly changed, had no RFC, use new function with name inconsistent with all existing functions with the same semantics (json_last_error_msg) and IMO do not belong in stable branches, especially not done this way. I intend to release 5.4.5 RC1 next week, and I want this matter to be cleared up before that, because I can not release it in this state. So we have two options here: 1. Revert everything to 5.4.4 state and deal with it in 5.5 or maybe in 5.4.6 if it'd be ready. 2. Have it cleaned up ASAP and brought to a state where there are no test failures and there's a clear description of what the changes were in NEWS and UPGRADING. I think option 2 is better, but if it can not happen by EOD Tuesday (July 3) I intend to go with option 1. Nikita, please advise how you prefer to proceed with this. Johannes, do you want me to revert it in 5.3 branch too in case we have to go with option 1? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: JSON changes in 5.3/5.4
On Sun, Jul 1, 2012 at 12:59 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I see that there were significant changes committed to JSON extension in 5.3 and 5.4 recently. These changes modify json_encode behavior, break tests (pass001.1_64bit.phpt does not work anymore for me), are not clearly documented and have no NEWS/UPGRADING entries describing what exactly changed, had no RFC, use new function with name inconsistent with all existing functions with the same semantics (json_last_error_msg) and IMO do not belong in stable branches, especially not done this way. I intend to release 5.4.5 RC1 next week, and I want this matter to be cleared up before that, because I can not release it in this state. So we have two options here: 1. Revert everything to 5.4.4 state and deal with it in 5.5 or maybe in 5.4.6 if it'd be ready. 2. Have it cleaned up ASAP and brought to a state where there are no test failures and there's a clear description of what the changes were in NEWS and UPGRADING. I think option 2 is better, but if it can not happen by EOD Tuesday (July 3) I intend to go with option 1. Nikita, please advise how you prefer to proceed with this. Johannes, do you want me to revert it in 5.3 branch too in case we have to go with option 1? Hi Stas! If you are okay with the changes in principle, I will fix the remaining issues asap. If you think that the changes are too intrusive for release branches, I'll gladly revert them for 5.3/5.4. I didn't quite expect that there will be so many changes. Apart from that one test, does anything else fail for you? I didn't notice that one test because I'm running on 32bit. Regarding documentation, should these changes be documented in detail in NEWS? Or does it suffice to update the documentation? For UPGRADING, which one should it go in? Just 5.3? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: JSON changes in 5.3/5.4
On Sun, 2012-07-01 at 01:14 +0200, Nikita Popov wrote: If you are okay with the changes in principle, I will fix the remaining issues asap. If you think that the changes are too intrusive for release branches, I'll gladly revert them for 5.3/5.4. I didn't quite expect that there will be so many changes. I think in 5.3 we don't need changes. 5.3 is a stable stable stable branch. Fixing bugs, ok, changing behavior: No go. I haven't looked at it in detail, though. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: JSON changes in 5.3/5.4
On Sun, Jul 1, 2012 at 1:27 AM, Johannes Schlüter johan...@schlueters.de wrote: I think in 5.3 we don't need changes. 5.3 is a stable stable stable branch. Fixing bugs, ok, changing behavior: No go. Agreed. One question: When I revert the changes to 5.3 should I also revert the original change that was released in 5.3.14? (http://git.php.net/?p=php-src.git;a=commit;h=3f3ad30c50c32327e723046bcc6649d05dd9236a) The change was reverted on 5.4, but was missed on 5.3. It is present only in that one release and is currently not documented in any way. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: JSON changes in 5.3/5.4
Hi! If you are okay with the changes in principle, I will fix the remaining issues asap. If you think that the changes are too intrusive for release branches, I'll gladly revert them for 5.3/5.4. I didn't quite expect that there will be so many changes. I think changes with adding new functions, etc. are too intrusive for 5.3/5.4. If you have any fixes that can be done without it, please describe them and let's see if they fit stable versions. Otherwise, let's go back to stable. In any case, the tests should be fixed too. Apart from that one test, does anything else fail for you? I didn't notice that one test because I'm running on 32bit. That's the only test that failed for me in 5.4. Regarding documentation, should these changes be documented in detail in NEWS? Or does it suffice to update the documentation? For UPGRADING, which one should it go in? Just 5.3? It would be best to have short description in UPGRADING and full description in the docs. NEWS should have short mention of it. But since we're talking about moving all substantial changes to 5.5, that's where it should be. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] concatenation operator
On Sat, 2012-06-30 at 03:53 -0700, Adi Mutu wrote: By initialization i mean the latest point possible where I can set a breakpoint, but right before my scripts starts executing it's emalloc's or efree's. Does executing include compilation? Does it include creating a stack frame etc. for the main routine? ... but even then you will see many things you're probably not interested in such as?.. Well, PHP is complex, it does quite a few things in order to run a seemingly small script. Only thing that helps is learning the code structure and digging through it. Any hint/documentation to learn that? Use the source. ;-) A bit more seriously: No, there's no good single place to look at, there are different blogs etc looking at specific pieces in detail, but the best thing to do is looking at the code (the filenames in Zend/ give a good idea what they are for ...), take a question and time and start digging. For some things it's also good to look into xdebug, vld, runkit, ... and see where they hook in to do their magic. And well, the path from main() in sapi/cli/php_cli.c to execute() is not that long, what then happens is a bit more complicated though (while then again, once you're in, quite easy for most parts, too) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
