[PHP-DEV] Re: Chasing an SSL stream segfault
On 04/01/2013 07:49 PM, Rasmus Lerdorf wrote: ==12085== Uninitialised value was created by a stack allocation ==12085==at 0x7B54530: ASN1_STRING_to_UTF8 (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) Looks like these ASN1_STRING_to_UTF8 ones are normal for libcrypto. Really hard to debug openssl stuff with all these Valgrind false positives. Still trying to track down the core on Centos 6.2. Looks like a weird build issue at this point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Chasing an SSL stream segfault
On 2 April 2013 08:50, Rasmus Lerdorf ras...@lerdorf.com wrote: Looks like these ASN1_STRING_to_UTF8 ones are normal for libcrypto. Really hard to debug openssl stuff with all these Valgrind false positives. Still trying to track down the core on Centos 6.2. Looks like a weird build issue at this point. Might not be related, but looks like we call SSL_CTX_use_certificate_chain_file with too less arguments: http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html (note the type parameter, apparently since 0.9.8). -- Regards, Mike
Re: [PHP-DEV] Re: Chasing an SSL stream segfault
On 2 April 2013 11:36, Michael Wallner m...@php.net wrote: On 2 April 2013 08:50, Rasmus Lerdorf ras...@lerdorf.com wrote: Looks like these ASN1_STRING_to_UTF8 ones are normal for libcrypto. Really hard to debug openssl stuff with all these Valgrind false positives. Still trying to track down the core on Centos 6.2. Looks like a weird build issue at this point. Might not be related, but looks like we call SSL_CTX_use_certificate_chain_file with too less arguments: http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html (note the type parameter, apparently since 0.9.8). The openssl extension might need some refreshing review in general then... -- Regards, Mike
Re: [PHP-DEV] Re: Chasing an SSL stream segfault
On 2 April 2013 11:36, Michael Wallner m...@php.net wrote: On 2 April 2013 08:50, Rasmus Lerdorf ras...@lerdorf.com wrote: Looks like these ASN1_STRING_to_UTF8 ones are normal for libcrypto. Really hard to debug openssl stuff with all these Valgrind false positives. Still trying to track down the core on Centos 6.2. Looks like a weird build issue at this point. Might not be related, but looks like we call SSL_CTX_use_certificate_chain_file with too less arguments: http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html (note the type parameter, apparently since 0.9.8). Nevermind, I actually confused *_chain_file with *_file ... -- Regards, Mike
Re: [PHP-DEV] Fix for bug #63437
hi, On Thu, Mar 14, 2013 at 4:32 PM, Anatol Belski a...@php.net wrote: One doubt I have yet after investigating on #62852 is that issuing php_error isn't recoverable, it might be much better to throw exception in __wakeup(), just like __construct() does. This question crosses both #62852 and #53437. That would work for 5.5 as unserialize() cares about exceptions in __wakeup(), in 5.4 and less php_error seems to be a better way. What do you think? I've reuploaded the patch, removed that extra checks, fixed the relevant tests, removed XFAIL from bug53437.phpt and added three more. https://bugs.php.net/patch-display.php?bug_id=53437patch=date_patch_var4.patchrevision=latest Tests pass, crashes are gone and the patch meets the requirements Derick asked earlier. If there is no further objection until next Monday I will ask Anatolyi to apply it and finally fix one of the only remaining known crash in 5.3/4, and indeed 5.5 and master (but there are other there :). Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] [RFC] more secure unserialize()
On 2013-03-31 00:27, Stas Malyshev wrote: Hi! I think Stas proposes a solution to the problem and I think Anthony proposes a viable alternative. I would say that Anthony has found the shortest distance between the two points (the problem and the solution), however. The fact is that people do use serialize() for data that may be accessible by the user (or made accessible by unrelated security issues, which may be upgraded in severity by this - e.g. from SQL injection to persistent code backdoor on the server). There are many ways to do things differently, and they are known. However, as I said, the fact is people do use serialize() and may not even realize the data aren't as secure as they are. That's why many security tools flag any object with dtor in application using unserialize as insecure. This is not a good situation, and presently there are no way to avoid it except dropping serialize() completely - which may not be an option is some cases and in any case would require serious changes to the production code. This enhancement is to fix this problem. It is not to change best practices or give advice on how to write the most secure system - it is to make existing code more secure easily. An alternative to whitelisting or forbidding unserialization of classes is to sign your serialized data. We do this in a couple of places where users have access to serialized data (cookies, forms). There's a private key on the server and serialized data is encoded with a signature at the end. Users cannot directly modify the serialized data because they can't resign it without the key. The server rejects invalid signatures before unserializing. Maybe PHP core could add signed_serialize($data, $key) and signed_unserialize($data, $key). Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 thanks On Mon, Apr 1, 2013 at 9:53 PM, Laruence larue...@php.net wrote: On Mon, Apr 1, 2013 at 7:18 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Mar 31, 2013 at 6:25 AM, Laruence larue...@php.net wrote: Hey: there are some issues when people run some codes in a php which is compiled with --with-curlwrappers, like #61336, or the recently test script for #64433 (failed when curl wrappers enabled). I know, that the curl wrapper should act the same as php http wrapper, but for now, we need to provide the ability to user, that they can warn if they codes can not run with curl wrappers.. here are some really usages: https://github.com/UnionOfRAD/lithium/issues/59 and http://weizhifeng.net/wrong-with-curlwrappers.html I propose to add a constant : bool CURL_WRAPPERS_ENABLE The curl wrappers have always been a major pain, with plenty of bugs and we tend to forget to add context options there to match the standard wrapper on new feature. It has been marked as experimental since forever, and I think its time to face the failed experiment and remove it. Hey: remove is also okey for me, but, I think it probably can only happen in 5.6 before that, I think a flag to 5.4+ is a good choice :) thanks -Hannes -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/
[PHP-DEV] [RFC] Simplified Array API for extensions
https://wiki.php.net/rfc/php-array-api -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
On 04/02/2013 07:52 PM, Sara Golemon wrote: https://wiki.php.net/rfc/php-array-api Very nice. I would love to see more of the API simplified for common tasks like this. It is a macro jungle currently. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
On Tue, Apr 2, 2013 at 9:14 PM, Rasmus Lerdorf wrote: On 04/02/2013 07:52 PM, Sara Golemon wrote: https://wiki.php.net/rfc/php-array-api Very nice. I would love to see more of the API simplified for common tasks like this. It is a macro jungle currently. -Rasmus Coming from a mostly user land developer but one that likes to attempt to navigate the internals this is a massive step forward. One of the hardest things coming from the outside is attempting to navigate the macro jungle as you call it. lxr certainly helps a massive amount but even sometimes understanding what those macros are supposed to be can a bit complex. Navigating a cleaner API such as this I believe will assist in a cleaner and much more clear implementation downstream. These types of changes to PHP can assist the PHP ecosystem in terms of contributors and overall maintenance of the language. - Mike
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Wait wait wait. You are introducing a constant that is going to be available as of 5.4.15 to 5.4.2x and then removed (as it looks like we are agreeing)? People have been living without this constant forever now so people have their workarounds in place and no need to complicate their code to for the existence of this constant which is only available for few bugfix releases anyway? -Hannes On Tue, Apr 2, 2013 at 7:19 PM, Laruence larue...@php.net wrote: Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 thanks On Mon, Apr 1, 2013 at 9:53 PM, Laruence larue...@php.net wrote: On Mon, Apr 1, 2013 at 7:18 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Mar 31, 2013 at 6:25 AM, Laruence larue...@php.net wrote: Hey: there are some issues when people run some codes in a php which is compiled with --with-curlwrappers, like #61336, or the recently test script for #64433 (failed when curl wrappers enabled). I know, that the curl wrapper should act the same as php http wrapper, but for now, we need to provide the ability to user, that they can warn if they codes can not run with curl wrappers.. here are some really usages: https://github.com/UnionOfRAD/lithium/issues/59 and http://weizhifeng.net/wrong-with-curlwrappers.html I propose to add a constant : bool CURL_WRAPPERS_ENABLE The curl wrappers have always been a major pain, with plenty of bugs and we tend to forget to add context options there to match the standard wrapper on new feature. It has been marked as experimental since forever, and I think its time to face the failed experiment and remove it. Hey: remove is also okey for me, but, I think it probably can only happen in 5.6 before that, I think a flag to 5.4+ is a good choice :) thanks -Hannes -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
