Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
hi Anthony, On Thu, Jun 28, 2012 at 9:36 PM, Anthony Ferrara ircmax...@gmail.com wrote: I haven't looked at your patch. But if it has to call another PHP_FuNCTION then it's not good. crypt implementation should be accessible via C. I've refactored crypt() slightly to expose a PHP_API crypt_execute() function that does just about everything except the argument parsing / default randomizing. https://github.com/ircmaxell/php-src/blob/hash_password/ext/standard/crypt.c It looks good. I would name it php_crypt instead. _execute means there is a prepare (well, there is but it is called on init :). 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
[PHP-DEV] Asking for a review of crypt() allocation changes
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 http://git.php.net/?p=php-src.git;a=commitdiff;h=e6cf7d774519300c08399cae5bfba90e33749727 The complete code is here: http://lxr.php.net/xref/PHP_TRUNK/ext/standard/crypt.c#150 To prevent another crypt() mess, I'd really appreciate if some people familiar with the code could look over it. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Asking for a review of crypt() allocation changes
Additionally, it appears that SHA256/512 are way overallocating the buffer. For SHA512: int needed = (sizeof(sha512_salt_prefix) - 1 + sizeof(sha512_rounds_prefix) + 9 + 1 + salt_in_len + 1 + 86 + 1); output = emalloc(needed); salt[salt_in_len] = '\0'; crypt_res = php_sha512_crypt_r(str, salt, output, needed); // snip memset(output, 0, needed); efree(output); The salt_in_len includes the salt_prefix and the rounds_prefix as well. Since salt_in_len (thanks to the allocations before hand) can be up to PHP_MAX_SALT_LEN http://lxr.php.net/xref/PHP_TRUNK/ext/standard/crypt.c#88 which is 123 characters, the output of the function can be no bigger than PHP_MAX_SALT_LEN. Therefore the needed variable can be replaced by PHP_MAX_SALT_LEN everywhere... output = emalloc(MAX_SALT_LEN); salt[salt_in_len] = '\0'; crypt_res = php_sha512_crypt_r(str, salt, output, MAX_SALT_LEN); // snip memset(output, 0, MAX_SALT_LEN); efree(output); We can do the same for sha256. But in that case, we'll be overallocating the buffer as well. Although not nearly as bad as we are now. Thoughts? Anthony On Fri, Jun 29, 2012 at 8:43 AM, Nikita Popov nikita@gmail.com 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 http://git.php.net/?p=php-src.git;a=commitdiff;h=e6cf7d774519300c08399cae5bfba90e33749727 The complete code is here: http://lxr.php.net/xref/PHP_TRUNK/ext/standard/crypt.c#150 To prevent another crypt() mess, I'd really appreciate if some people familiar with the code could look over it. Nikita -- 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
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
Bumping this for a last call RFC. It will be 2 weeks on Monday since the proposal, and since there's not been a lot of traffic on the discussion, I'm planning on putting it up to a vote at that time (unless there are any major objections raised). So if anyone wants to comment prior to the vote, please do so! https://wiki.php.net/rfc/hash_pbkdf2 Anthony On Thu, Jun 21, 2012 at 7:41 AM, Anthony Ferrara ircmax...@gmail.com wrote: Pierre, I would update the RFC with the current available algorithms or recommended to be used (depending on the usage or goal). When you say currently available algorithms, are you talking about the hash library as a whole? Or recommended for use with PBKDF2? Or other iterated stretching algorithms similar to PBKDF2? The algos recommended to use with PBKDF2. I just updated the RFC to include a description of the non-obvious parameters ($password isn't described). I also included a bit on algorithm selection in there. Take a peak and let me know if that satisfies what you were looking for, or if it needs to be expanded further. Thanks again, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC proposal - Syntactic sugar for cloning
Hello everybody, It's the first time I write on the internals mailing-list, so let me introduce myself quickly. I'm a french and canadian CTO, working in Paris. I lead some PHP projects (mainly the Temma framework and FineFS data replication system). I begin to learn PHP's internal engine, backed by Pierrick Charron. I would like to do an RFC proposal (see below for the associated patch). I was thinking about what if PHP was a full-object language?. Like, for example, how will we write the simplest code, assuming that objects are handled using pointers since PHP 5. Take a look at this code: $a = 3; $b = $a; $a++; $b still contains the value 3. Now, if we imagine that even the integer data type is managed in an object, the same code will produce two pointers to the same object. Thus, $b will have the value 4, as $a. So, in this imaginary world, we would need to do a lot of object cloning. I wondered how this could be less painful, and I thought about the Pascal language's affectation operator (:=). Then we would be able to write something like that: $a = 3; $b := $a; $c = $a; $a++; $a equals 4, as $c. But $b equals 3. Back in the real world, we are not cloning objects very often. But, like many other syntactic sugars (as the short array syntax), I think it could be handy in some circumstances. There is a patch for this evolution, written by Pierrick. Full source code: https://github.com/adoy/php-src/tree/amaury-clone Code diff: https://github.com/adoy/php-src/commit/5107c0355c50381c7e67230cdc9f563eb3936a15 I'm looking forward to your advices. Cheers! Amaury
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
On Fri, 2012-06-29 at 16:25 +0200, Amaury Bouchard wrote: Back in the real world, we are not cloning objects very often. But, like many other syntactic sugars (as the short array syntax), I think it could be handy in some circumstances. Well, arrays are used all over the place. As you said: cloning is not. Also this patch only covers one use case, the assignment of an copy. I does not cover other cases, like cloning in an function call foo(clone $obj); etc. So I see little need for that sugar, it will mostly hurt the teeth (to stay in the picture) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
2012/6/29 Amaury Bouchard ama...@amaury.net: Hello everybody, It's the first time I write on the internals mailing-list, so let me introduce myself quickly. I'm a french and canadian CTO, working in Paris. I lead some PHP projects (mainly the Temma framework and FineFS data replication system). I begin to learn PHP's internal engine, backed by Pierrick Charron. I would like to do an RFC proposal (see below for the associated patch). I was thinking about what if PHP was a full-object language?. Like, for example, how will we write the simplest code, assuming that objects are handled using pointers since PHP 5. Take a look at this code: $a = 3; $b = $a; $a++; $b still contains the value 3. Now, if we imagine that even the integer data type is managed in an object, the same code will produce two pointers to the same object. Thus, $b will have the value 4, as $a. So, in this imaginary world, we would need to do a lot of object cloning. I wondered how this could be less painful, and I thought about the Pascal language's affectation operator (:=). Then we would be able to write something like that: $a = 3; $b := $a; $c = $a; $a++; $a equals 4, as $c. But $b equals 3. Back in the real world, we are not cloning objects very often. But, like many other syntactic sugars (as the short array syntax), I think it could be handy in some circumstances. There is a patch for this evolution, written by Pierrick. Full source code: https://github.com/adoy/php-src/tree/amaury-clone Code diff: https://github.com/adoy/php-src/commit/5107c0355c50381c7e67230cdc9f563eb3936a15 I'm looking forward to your advices. Cheers! Amaury Hi Amaury, I have to agree with Johannes here, it looks like a benefit only in a very few cases but introduces a lot of side changes like IDE syntax parsing, to cite only one. I really doubt the little benefit of such a change outperforms the extra work involved. Cheers, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Asking for a review of crypt() allocation changes
On 06/29/2012 05:56 AM, Anthony Ferrara wrote: Additionally, it appears that SHA256/512 are way overallocating the buffer. For SHA512: int needed = (sizeof(sha512_salt_prefix) - 1 + sizeof(sha512_rounds_prefix) + 9 + 1 + salt_in_len + 1 + 86 + 1); output = emalloc(needed); salt[salt_in_len] = '\0'; crypt_res = php_sha512_crypt_r(str, salt, output, needed); // snip memset(output, 0, needed); efree(output); The salt_in_len includes the salt_prefix and the rounds_prefix as well. Since salt_in_len (thanks to the allocations before hand) can be up to PHP_MAX_SALT_LEN http://lxr.php.net/xref/PHP_TRUNK/ext/standard/crypt.c#88 which is 123 characters, the output of the function can be no bigger than PHP_MAX_SALT_LEN. Therefore the needed variable can be replaced by PHP_MAX_SALT_LEN everywhere... output = emalloc(MAX_SALT_LEN); salt[salt_in_len] = '\0'; crypt_res = php_sha512_crypt_r(str, salt, output, MAX_SALT_LEN); // snip memset(output, 0, MAX_SALT_LEN); efree(output); We can do the same for sha256. But in that case, we'll be overallocating the buffer as well. Although not nearly as bad as we are now. Thoughts? We need to get into the habit of using safe_emalloc() on any emalloc() that takes its size from a user-provided argument. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
hi, On Fri, Jun 29, 2012 at 4:19 PM, Anthony Ferrara ircmax...@gmail.com wrote: Bumping this for a last call RFC. It will be 2 weeks on Monday since the proposal, and since there's not been a lot of traffic on the discussion, I'm planning on putting it up to a vote at that time (unless there are any major objections raised). So if anyone wants to comment prior to the vote, please do so! https://wiki.php.net/rfc/hash_pbkdf2 Quick reminder, it will be -1 from here if it targets 5.4, for all the reasons I have been repeatedly explaining. 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
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
I also agree with Johannes. Pierrick On 29 June 2012 11:01, Patrick ALLAERT patrickalla...@php.net wrote: 2012/6/29 Amaury Bouchard ama...@amaury.net: Hello everybody, It's the first time I write on the internals mailing-list, so let me introduce myself quickly. I'm a french and canadian CTO, working in Paris. I lead some PHP projects (mainly the Temma framework and FineFS data replication system). I begin to learn PHP's internal engine, backed by Pierrick Charron. I would like to do an RFC proposal (see below for the associated patch). I was thinking about what if PHP was a full-object language?. Like, for example, how will we write the simplest code, assuming that objects are handled using pointers since PHP 5. Take a look at this code: $a = 3; $b = $a; $a++; $b still contains the value 3. Now, if we imagine that even the integer data type is managed in an object, the same code will produce two pointers to the same object. Thus, $b will have the value 4, as $a. So, in this imaginary world, we would need to do a lot of object cloning. I wondered how this could be less painful, and I thought about the Pascal language's affectation operator (:=). Then we would be able to write something like that: $a = 3; $b := $a; $c = $a; $a++; $a equals 4, as $c. But $b equals 3. Back in the real world, we are not cloning objects very often. But, like many other syntactic sugars (as the short array syntax), I think it could be handy in some circumstances. There is a patch for this evolution, written by Pierrick. Full source code: https://github.com/adoy/php-src/tree/amaury-clone Code diff: https://github.com/adoy/php-src/commit/5107c0355c50381c7e67230cdc9f563eb3936a15 I'm looking forward to your advices. Cheers! Amaury Hi Amaury, I have to agree with Johannes here, it looks like a benefit only in a very few cases but introduces a lot of side changes like IDE syntax parsing, to cite only one. I really doubt the little benefit of such a change outperforms the extra work involved. Cheers, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
Pierre, Quick reminder, it will be -1 from here if it targets 5.4, for all the reasons I have been repeatedly explaining. I've updated the RFC to indicate such (that it's only targeting master (5.5)). Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
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 :
Re: [PHP-DEV] concatenation operator
Hello,
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.
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.
dtrace related:
Why have you used 'execute:return' and not concat_function:return? What's with
the execute function?
Thanks,
A.
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: Thursday, June 7, 2012 11:18 PM
Subject: Re: [PHP-DEV] concatenation operator
On Thu, 2012-06-07 at 12:53 -0700, Adi Mutu wrote:
Ok Johannes, thanks for the answer. I'll try to look deeper.
I basically just wanted to know what happens when you concatenate two
strings? what emalloc/efree happens.
This depends. As always. As said what has to be done is one allocation
for the result value ... and then the zval magic, which depends on
refcount, references, ...
Also can you tell me if possible how to put a breakpoint to
emalloc/efree which are executed only after all core functions are
registered? because it takes like a million years like this and a
million F8 presses...
Depends on your debugger. Most allow conditional breakpoints or have a
breakpoint and while holding at some place add a few more ...
For such a question my preference is using DTrace (on Solaris, Mac or
BSD), something like this session:
$ cat test.d
#!/sbin/dtrace
pid$target::concat_function:entry {
self-in_concat = 1;
}
pid$target::execute:return {
self-in_concat = 0;
}
pid$target::_emalloc:entry
/ self-in_concat /
{
trace(arg0);
ustack();
}
pid$target::_erealloc:entry
/ self-in_concat /
{
trace(arg0);
trace(arg1);
ustack();
}
$ cat test1.php
?php
$a = foo; $b = bar; $a.$b;
$ dtrace -s test.d -c 'php test1.php'
dtrace: script 'test.d' matched 4 probes
dtrace: pid 16406 has exited
CPU ID FUNCTION:NAME
3 100372 _emalloc:entry 7
php`_emalloc
php`concat_function+0x270
php`ZEND_CONCAT_SPEC_CV_CV_HANDLER+0xcd
php`execute+0x3d9
php`dtrace_execute+0xe7
php`zend_execute_scripts+0xf5
php`php_execute_script+0x2e8
php`do_cli+0x864
php`main+0x6e2
php`_start+0x83
$ cat test2.php
?php
$a = 23; $b = bar; $a.$b;
$ dtrace -s test.d -c 'php test2.php'
dtrace: script 'test.d' matched 4 probes
dtrace: pid 16425 has exited
CPU ID FUNCTION:NAME
1 100373 _erealloc:entry 0
79
php`_erealloc
php`xbuf_format_converter+0x11ee
php`vspprintf+0x34
php`zend_spprintf+0x2f
php`_convert_to_string+0x174
php`zend_make_printable_zval+0x5ec
php`concat_function+0x3c
php`ZEND_CONCAT_SPEC_CV_CV_HANDLER+0xcd
php`execute+0x3d9
php`dtrace_execute+0xe7
php`zend_execute_scripts+0xf5
php`php_execute_script+0x2e8
php`do_cli+0x864
php`main+0x6e2
php`_start+0x83
1 100372 _emalloc:entry 6
php`_emalloc
php`concat_function+0x270
php`ZEND_CONCAT_SPEC_CV_CV_HANDLER+0xcd
php`execute+0x3d9
php`dtrace_execute+0xe7
php`zend_execute_scripts+0xf5
php`php_execute_script+0x2e8
php`do_cli+0x864
php`main+0x6e2
php`_start+0x83
So, when having two constant strings there's a single malloc, in this
case allocating 7 bytes (strlen(foo)+strlen(bar)+1), if you have a
different type it has to be converted first ...
johannes
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
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 :
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
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 :
