[PHP-DEV] How to publish extesion on pecl.php.net?
Hello, I have written an extension using C language, I wrote an email to pecl-...@lists.php.net according to "Publishing in PECL Requirement", but the spam prevention measure blocked me , I replied confirmation email both in text format and html format email with the code given to me, and I also tried to reply the email both in text format and html format email with the code given to me, however all of these four email got no response! What should I do? Thanks! event2game
Re: [PHP-DEV] How to publish extesion on pecl.php.net?
hi, On Wed, Sep 12, 2012 at 9:34 AM, event2game wrote: > Hello, > > I have written an extension using C language, > > I wrote an email to pecl-...@lists.php.net according to "Publishing in PECL > Requirement", > but the spam prevention measure blocked me , I replied confirmation email > both in text format and html format email with the code given to me, and I > also tried to reply the email both in text format and html format email with > the code given to me, > however all of these four email got no response! Please try first to subscribe to the pecl-dev mailing list. HTML email should be avoided at any price :) 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] PHP build-in HTTP server and the HEAD method
Hello, It is probably me but it seems like the build-in HTTP server does not well support the HEAD method. Here is my following test case. First, the foo.php file: /dev/null 2>&1 & $ # Test with POST. $ curl -v -X POST 127.0.0.1: * About to connect() to 127.0.0.1 port (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port (#0) > POST / HTTP/1.1 > User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 > Host: 127.0.0.1: > Accept: */* > < HTTP/1.1 200 OK < Host: 127.0.0.1: < Connection: close < X-Powered-By: PHP/5.5.0-dev < Content-type: text/html < string(4) "POST" * Closing connection #0 $ # It works, cool. $ # Now, test with HEAD. $ curl -v -X HEAD 127.0.0.1: * About to connect() to 127.0.0.1 port (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port (#0) > HEAD / HTTP/1.1 > User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 > Host: 127.0.0.1: > Accept: */* > < HTTP/1.1 200 OK < Host: 127.0.0.1: < Connection: close < X-Powered-By: PHP/5.5.0-dev < Content-type: text/html < * Closing connection #0 I have to admit that I don't understand, even by looking at the source code. Thoughts? Thanks. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/
Re: [PHP-DEV] PHP build-in HTTP server and the HEAD method
On Wed, Sep 12, 2012 at 10:54 AM, Ivan Enderlin @ Hoa wrote: > Hello, > > It is probably me but it seems like the build-in HTTP server does not well > support the HEAD method. Here is my following test case. First, the foo.php > file: > > >var_dump($_SERVER['REQUEST_METHOD']); By definition, a HEAD request MUST NOT return a message-body. This works as expected: Here is how it works: main/SAPI.c has code that set SG(request_info).headers_only = 1 for HEAD requests, and as a consequence php_request_shutdown() does not flush the output buffer (if any) to the client. You can force a body to be sent (but that's likely not going to work with every SAPI) by not having an output buffer or by calling ob_end_flush() yourself. Damien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars
Hi Ralph, I've tested the feature/class_name_scalar in your repo on Windows. Both TS and NTS build and pass the test. Regards Anatoliy Am Di, 11.09.2012, 16:39 schrieb Ralph Schindler: > Hi internals! > > The ::class resolution proposal had significant discussion in April and > I've updated the patch to address issues that came up then. At this > point, I've gotten some positive feedback from various places and feel > its time to open it up for a vote to internals. > > RFC: https://wiki.php.net/rfc/class_name_scalars#vote > > PR: https://github.com/php/php-src/pull/187 > > Thanks, > Ralph > > -- > 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] PHP build-in HTTP server and the HEAD method
Hi, As far as I can see everything works as expected: Because HEAD-requests should not send any content, you don't get any. Regards, Sebastian 2012/9/12 Ivan Enderlin @ Hoa > Hello, > > It is probably me but it seems like the build-in HTTP server does not well > support the HEAD method. Here is my following test case. First, the foo.php > file: > > >var_dump($_SERVER['REQUEST_**METHOD']); > > > And then: > >$ # Run the server. >$ php -S 127.0.0.1: -t . foo.php > /dev/null 2>&1 & > >$ # Test with POST. >$ curl -v -X POST 127.0.0.1: >* About to connect() to 127.0.0.1 port (#0) >* Trying 127.0.0.1... >* connected >* Connected to 127.0.0.1 (127.0.0.1) port (#0) > > POST / HTTP/1.1 > > User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r >zlib/1.2.5 > > Host: 127.0.0.1: > > Accept: */* > > >< HTTP/1.1 200 OK >< Host: 127.0.0.1: >< Connection: close >< X-Powered-By: PHP/5.5.0-dev >< Content-type: text/html >< >string(4) "POST" >* Closing connection #0 >$ # It works, cool. > >$ # Now, test with HEAD. >$ curl -v -X HEAD 127.0.0.1: >* About to connect() to 127.0.0.1 port (#0) >* Trying 127.0.0.1... >* connected >* Connected to 127.0.0.1 (127.0.0.1) port (#0) > > HEAD / HTTP/1.1 > > User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r >zlib/1.2.5 > > Host: 127.0.0.1: > > Accept: */* > > >< HTTP/1.1 200 OK >< Host: 127.0.0.1: >< Connection: close >< X-Powered-By: PHP/5.5.0-dev >< Content-type: text/html >< >* Closing connection #0 > > > I have to admit that I don't understand, even by looking at the source > code. > > Thoughts? > Thanks. > > -- > Ivan Enderlin > Developer of Hoa > http://hoa.42/ or http://hoa-project.net/ > > PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) > http://disc.univ-fcomte.fr/ and http://www.inria.fr/ > > Member of HTML and WebApps Working Group of W3C > http://w3.org/ > > -- github.com/KingCrunch
Re: [PHP-DEV] PHP build-in HTTP server and the HEAD method
On 12/09/12 11:15, Damien Tournoud wrote: On Wed, Sep 12, 2012 at 10:54 AM, Ivan Enderlin @ Hoa wrote: Hello, It is probably me but it seems like the build-in HTTP server does not well support the HEAD method. Here is my following test case. First, the foo.php file: By definition, a HEAD request MUST NOT return a message-body. Oh grrr, I feel stupid now ;-). I forget this. This works as expected: Here is how it works: main/SAPI.c has code that set SG(request_info).headers_only = 1 for HEAD requests, and as a consequence php_request_shutdown() does not flush the output buffer (if any) to the client. Ok. You can force a body to be sent (but that's likely not going to work with every SAPI) by not having an output buffer or by calling ob_end_flush() yourself. Yes but that was not my goal. Thank you for your reply :-). -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP build-in HTTP server and the HEAD method
On 12/09/12 11:20, Sebastian Krebs wrote: Hi, Hi, As far as I can see everything works as expected: Because HEAD-requests should not send any content, you don't get any. Yup, as Damien said. Thank you. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
Hello all, I've closed the vote and it's been accepted with a vote total of 19:0, unanimous. I've moved the RFC into Accepted. I'm going to add the remaining tests, and then move it into master later. As for the PECL extension route, I'll work on splitting it into a PECl extension for 5.3/5.4 at the same time. Thanks all, Anthony On Tue, Sep 11, 2012 at 7:58 AM, Anthony Ferrara wrote: > Hannes, > > > First off, this has been discussed on the list for literally months. Why >> > wait until the day before voting can end before bringing this up? >> >> So commenting is strictly forbidden during votes? > > > Not in the least. Just pointing out that this discussion could have been > better if it was started much earlier (prior to the time and effort being > put into it). Just pointing it out. There's nothing "wrong" (procedurally) > about bringing it up now, just that it would have been nice to hear this > point earlier in the discussion... > > >> > Secondly, the main reason for not developing this as an extension is >> that >> > there's really no benefit to it. There are little to no performance >> gains to >> > be had by the C implementation. It can live quite as easily as a PHP >> > library. >> >> The benefit is that it can be tested properly and bugs discovered and >> ironed out first. >> > > I'm not so sure about that. If it was widely adopted as an extension, > sure. But I would predict a very limited adoption. Almost purely academic. > The reason is that there's no advantage to doing it in C other than to > provide a working API for those who don't understand how to build it (or > realize the benefits thereto). Those are the same people who wouldn't be > able to install a PECL extension (know-how or access). And projects who > realize this is needed are likely already using one of the many libraries > available. > > So I'm not sure the install rate would be anywhere high enough to work any > significant issues out. Additionally, there are testing phases for the > release that would hopefully catch any major issues prior to 5.5 going > gold... > > >> This is not the sort of thing you want to get security bug reports the >> day after its released in core. >> > > Sure. Which is why I've been going around looking for security reviews > (posted to the crypt-dev list on openwall, and to > security.stackexchange.com). > > >> If your ego is big enough you can guarantee you have tested this >> thoroughly and want it to become the recommended way.. You have to be >> damn sure you don't fuck it up. >> > > I want to say that this is really unfair. By saying it this way you've > pushed me into a corner. I disagree that your suggestion would have a > result of any significant gain in security. Yet I cannot disagree with you > without coming across as an egotist now that you said it that way. Please > try to keep things civil without setting up traps to try to prove your > point. I don't appreciate this remark at all... > > >> This is exactly the sort of thing that doesn't need to be developed in >> the core tree, but can later be merged in once proven successful. >> > > As indicated before, if that's the case, then it would never be merged. > Because this would never be successful as a stand alone PECL module. The > primary reason for adding it is so that people who don't know any better > would be able to use a secure API. That is the antithesis of a PECL > extension. > > >> >> Especially considering the patch is unfinished. >> > >> > >> > Aside from adding a few more tests, what's unfinished? If you're >> referring >> > to the line in the RFC, I just haven't updated it. The patch has been >> worked >> > on and is in a place where I'd be comfortable submitting it... >> >> The test suite seems very limited, and the code seems to be waiting >> for more algorithms to be implemented. >> > > Yes, the test suite needs to be expanded. I tested it additionally with > the PHPUnit tests that I wrote for the PHP fallback, so it's been tested > fairly well... I just need to expand the phpt test suite included in core... > > As far as more algorithms, right now there's no reason to add more > algorithms. The whole point was to never add anything but the strongest > algorithm available. Which today is bcrypt. But as time goes on, and better > algorithms become available, the API is designed so that they can be > implemented. But today, there's no other algorithm that should be > implemented. (SCrypt is a candidate, but since it lacks crypt(3) bindings, > and is still very young, it's inclusion isn't prudent at this point). > > There's a section to the RFC for adding new algorithms as time goes on: > https://wiki.php.net/rfc/password_hash#updating_password_default > > Anthony >
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
All, I have added the tests and ensured that everything seems pretty clean. I have opened a Pull Request for this item as I would like to get more eyes on it (especially since it touches crypt()). Please review the PR and comment away. https://github.com/php/php-src/pull/191/files Once it looks good, I'll merge it in. I just wanted to get more eyes on the diff first... Thanks Anthony On Wed, Sep 12, 2012 at 10:02 AM, Anthony Ferrara wrote: > Hello all, > > I've closed the vote and it's been accepted with a vote total of 19:0, > unanimous. I've moved the RFC into Accepted. > > I'm going to add the remaining tests, and then move it into master later. > > As for the PECL extension route, I'll work on splitting it into a PECl > extension for 5.3/5.4 at the same time. > > Thanks all, > > Anthony > > On Tue, Sep 11, 2012 at 7:58 AM, Anthony Ferrara wrote: > >> Hannes, >> >> > First off, this has been discussed on the list for literally months. >>> Why >>> > wait until the day before voting can end before bringing this up? >>> >>> So commenting is strictly forbidden during votes? >> >> >> Not in the least. Just pointing out that this discussion could have been >> better if it was started much earlier (prior to the time and effort being >> put into it). Just pointing it out. There's nothing "wrong" (procedurally) >> about bringing it up now, just that it would have been nice to hear this >> point earlier in the discussion... >> >> >>> > Secondly, the main reason for not developing this as an extension is >>> that >>> > there's really no benefit to it. There are little to no performance >>> gains to >>> > be had by the C implementation. It can live quite as easily as a PHP >>> > library. >>> >>> The benefit is that it can be tested properly and bugs discovered and >>> ironed out first. >>> >> >> I'm not so sure about that. If it was widely adopted as an extension, >> sure. But I would predict a very limited adoption. Almost purely academic. >> The reason is that there's no advantage to doing it in C other than to >> provide a working API for those who don't understand how to build it (or >> realize the benefits thereto). Those are the same people who wouldn't be >> able to install a PECL extension (know-how or access). And projects who >> realize this is needed are likely already using one of the many libraries >> available. >> >> So I'm not sure the install rate would be anywhere high enough to work >> any significant issues out. Additionally, there are testing phases for the >> release that would hopefully catch any major issues prior to 5.5 going >> gold... >> >> >>> This is not the sort of thing you want to get security bug reports the >>> day after its released in core. >>> >> >> Sure. Which is why I've been going around looking for security reviews >> (posted to the crypt-dev list on openwall, and to >> security.stackexchange.com). >> >> >>> If your ego is big enough you can guarantee you have tested this >>> thoroughly and want it to become the recommended way.. You have to be >>> damn sure you don't fuck it up. >>> >> >> I want to say that this is really unfair. By saying it this way you've >> pushed me into a corner. I disagree that your suggestion would have a >> result of any significant gain in security. Yet I cannot disagree with you >> without coming across as an egotist now that you said it that way. Please >> try to keep things civil without setting up traps to try to prove your >> point. I don't appreciate this remark at all... >> >> >>> This is exactly the sort of thing that doesn't need to be developed in >>> the core tree, but can later be merged in once proven successful. >>> >> >> As indicated before, if that's the case, then it would never be merged. >> Because this would never be successful as a stand alone PECL module. The >> primary reason for adding it is so that people who don't know any better >> would be able to use a secure API. That is the antithesis of a PECL >> extension. >> >> >>> >> Especially considering the patch is unfinished. >>> > >>> > >>> > Aside from adding a few more tests, what's unfinished? If you're >>> referring >>> > to the line in the RFC, I just haven't updated it. The patch has been >>> worked >>> > on and is in a place where I'd be comfortable submitting it... >>> >>> The test suite seems very limited, and the code seems to be waiting >>> for more algorithms to be implemented. >>> >> >> Yes, the test suite needs to be expanded. I tested it additionally with >> the PHPUnit tests that I wrote for the PHP fallback, so it's been tested >> fairly well... I just need to expand the phpt test suite included in core... >> >> As far as more algorithms, right now there's no reason to add more >> algorithms. The whole point was to never add anything but the strongest >> algorithm available. Which today is bcrypt. But as time goes on, and better >> algorithms become available, the API is designed so that they can be >> implemented. But today, there's no other algorit
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
Concerns about the RFC after talking with someone (Alok) on our security team at work. "There is no requirement for them to be cryptographically secure. " What stops the salt from being cryptographically secure? I think it should be a goal or we should state what parts aren't cryptographically secure, is it the random data source? "The salt parameter, if provided, will be used in place of an auto-generated salt." This is setting someone up for failure by letting them put in something weak, you should be forced to get an auto-generated salt. If this is for unit testing then it should be explicitly stated. The documentation also needs improved around password_needs_rehash. Tell the developer that at login time (or any other password validation time), if the options have changed, the password can be rehashed. E_WARNING in a crypto function is also bad. Throw an exception or fatal. There's no reason to just raise a warning and continue execution, if something went wrong in crypto then its a bad time for everyone. - S On 12 Sep 2012, at 09:02, Anthony Ferrara wrote: > All, > > I have added the tests and ensured that everything seems pretty clean. I > have opened a Pull Request for this item as I would like to get more eyes > on it (especially since it touches crypt()). Please review the PR and > comment away. > > https://github.com/php/php-src/pull/191/files > > Once it looks good, I'll merge it in. I just wanted to get more eyes on the > diff first... > > Thanks > > Anthony > > On Wed, Sep 12, 2012 at 10:02 AM, Anthony Ferrara wrote: > >> Hello all, >> >> I've closed the vote and it's been accepted with a vote total of 19:0, >> unanimous. I've moved the RFC into Accepted. >> >> I'm going to add the remaining tests, and then move it into master later. >> >> As for the PECL extension route, I'll work on splitting it into a PECl >> extension for 5.3/5.4 at the same time. >> >> Thanks all, >> >> Anthony >> >> On Tue, Sep 11, 2012 at 7:58 AM, Anthony Ferrara wrote: >> >>> Hannes, >>> First off, this has been discussed on the list for literally months. Why > wait until the day before voting can end before bringing this up? So commenting is strictly forbidden during votes? >>> >>> >>> Not in the least. Just pointing out that this discussion could have been >>> better if it was started much earlier (prior to the time and effort being >>> put into it). Just pointing it out. There's nothing "wrong" (procedurally) >>> about bringing it up now, just that it would have been nice to hear this >>> point earlier in the discussion... >>> >>> > Secondly, the main reason for not developing this as an extension is that > there's really no benefit to it. There are little to no performance gains to > be had by the C implementation. It can live quite as easily as a PHP > library. The benefit is that it can be tested properly and bugs discovered and ironed out first. >>> >>> I'm not so sure about that. If it was widely adopted as an extension, >>> sure. But I would predict a very limited adoption. Almost purely academic. >>> The reason is that there's no advantage to doing it in C other than to >>> provide a working API for those who don't understand how to build it (or >>> realize the benefits thereto). Those are the same people who wouldn't be >>> able to install a PECL extension (know-how or access). And projects who >>> realize this is needed are likely already using one of the many libraries >>> available. >>> >>> So I'm not sure the install rate would be anywhere high enough to work >>> any significant issues out. Additionally, there are testing phases for the >>> release that would hopefully catch any major issues prior to 5.5 going >>> gold... >>> >>> This is not the sort of thing you want to get security bug reports the day after its released in core. >>> >>> Sure. Which is why I've been going around looking for security reviews >>> (posted to the crypt-dev list on openwall, and to >>> security.stackexchange.com). >>> >>> If your ego is big enough you can guarantee you have tested this thoroughly and want it to become the recommended way.. You have to be damn sure you don't fuck it up. >>> >>> I want to say that this is really unfair. By saying it this way you've >>> pushed me into a corner. I disagree that your suggestion would have a >>> result of any significant gain in security. Yet I cannot disagree with you >>> without coming across as an egotist now that you said it that way. Please >>> try to keep things civil without setting up traps to try to prove your >>> point. I don't appreciate this remark at all... >>> >>> This is exactly the sort of thing that doesn't need to be developed in the core tree, but can later be merged in once proven successful. >>> >>> As indicated before, if that's the case, then it would never be merged. >>> Because this wo
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
On Wed, Sep 12, 2012 at 12:57 PM, Scott MacVicar wrote: > "There is no requirement for them to be cryptographically secure. " > What stops the salt from being cryptographically secure? I think it should be > a goal or we should state what parts aren't cryptographically secure, is it > the random data source? A salt (similar to a nonce), only needs to be unique within the system (see "Practical Cryptography" by Ferguson and Schneier) > "The salt parameter, if provided, will be used in place of an auto-generated > salt." > This is setting someone up for failure by letting them put in something weak, > you should be forced to get an auto-generated salt. If this is for unit > testing then it should be explicitly stated. Again, the salt is only weak IFF it is not unique within that particular system (app, website, etc.) Making the easier option be the one that ensures the uniqueness seems reasonable here, as most developers will use the provided functionality, whilst maintaining the developers more comfortable with the security requirements involved with customization to do so with some modest extra work. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
Scott, On Wed, Sep 12, 2012 at 12:57 PM, Scott MacVicar wrote: > Concerns about the RFC after talking with someone (Alok) on our security > team at work. > > "There is no requirement for them to be cryptographically secure. " > What stops the salt from being cryptographically secure? I think it should > be a goal or we should state what parts aren't cryptographically secure, is > it the random data source? > What stops it? Nothing. You can use a CS random string for a salt. That's fine. The point was that salts don't need to be CS to work. There's no requirement that they be CS (which is what I said). In fact, the only requirement is that they be unique. Not purely globally unique, but unique to the point that there's a very insignificant chance that anyone else is using the same settings with that same salt. Even if it's on a different application... Now, given that the only good CS source on most machines is /dev/random, and that it is blocking if it runs out of entropy, there's good reason to not use them unless you need them. So my approach is to only use CS randomness when I need it (key generation mainly). Cases when the quality of randomness significantly impacts the security. So the line is in there because the generated random salt is generated by /dev/urandom. I just wanted to make that distinction clear. > "The salt parameter, if provided, will be used in place of an > auto-generated salt." > This is setting someone up for failure by letting them put in something > weak, you should be forced to get an auto-generated salt. If this is for > unit testing then it should be explicitly stated. > It's there because some use-cases may dictate using a CS random salt. In those cases, you can read from /dev/random (or use mcrypt, etc) to generate the salt. The vast majority should not generate that salt parameter though. And that will be reflected in the documentation. > The documentation also needs improved around password_needs_rehash. Tell > the developer that at login time (or any other password validation time), > if the options have changed, the password can be rehashed. > Absolutely. That's why that function exists. I did not try to make the RFC into end-user documentation. In fact, I explicitly tried to avoid doing that. I wanted the RFC to be the technical justification and explanation. The end-user documentation will be made later, and it will include information like that (including examples)... > E_WARNING in a crypto function is also bad. Throw an exception or fatal. > There's no reason to just raise a warning and continue execution, if > something went wrong in crypto then its a bad time for everyone. I partially agree. I think a FATAL is a bit much (especially if it's a recoverable error, such as an invalid param). And exceptions are out (not allowed in core functions). I think the warning is the best approach, since it will always return a value conducive with the error (NULL or FALSE, depending on the function). If it returns a value, it's because no warning was thrown... Anthony
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
Hi! > "The salt parameter, if provided, will be used in place of an > auto-generated salt." This is setting someone up for failure by > letting them put in something weak, you should be forced to get an > auto-generated salt. If this is for unit testing then it should be > explicitly stated. This assumes that we have the best salt generation algorithm that ever existed or could exist, and never would have any bugs or vulnerabilities in it. If it's not the case, it makes sense to let people provide their own salts in case they can generate better ones. > E_WARNING in a crypto function is also bad. Throw an exception or > fatal. There's no reason to just raise a warning and continue > execution, if something went wrong in crypto then its a bad time for > everyone. This means the function will be behaving differently than other PHP functions. Because it's crypto and very important, I understand. But then comes somebody else and says "my file functions are super-important too, whole application depends on them, why can't I have them work the same as crypto ones?", etc. Core should be consistent in its responses. Also, since the function returns false on failure, you can easily know something went wrong and throw exception/produce fatal error there if you wanted. Just like other functions - e.g. fopen() - do. -- 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
