[PHP-DEV] Re: [External] : [RFC} Unbundle ext/imap, ext/pspell, and ext/oci8
On 27/9/2023 11:27 pm, Derick Rethans wrote: Hi, after the initial introduction, here is the formal RFC to unbundle the imap, pspell, and oci8 extensions and move them to PECL, for PHP 8.4. https://wiki.php.net/rfc/unbundle_imap_pspell_oci8 cheers, Derick Hi Derick, A small point: the bug URL for OCI8 in the RFC includes issues for PDO_OCI - which is not part of the RFC. Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Audit Priorities
Hi! This reminds me of something. There's an interesting paper about ReDoS resilience in different regex engines. Some programming languages, including PHP, are evaluated there and compared: https://www.usenix.org/system/files/sec22-turonova.pdf PHP has some configuration knobs for pcre (https://www.php.net/manual/en/pcre.configuration.php), not a lot to tune but maybe they can be? To be honest, I haven't looked much into this. Interesting topics, but I think not the top priority for the security audit, due to the fact that in PHP common use, regexps rarely come from a third party, and if they do (e.g. if you're writing a RE-driven search engine) you'd probably have potentially expensive searches anyway and thus make some ways to deal with it. In general, I think there are two security aspects we're dealing with - one is guarding PHP user from a hostile third party, and another is guarding PHP developer from writing the code that may expose the end user. I think the former is the higher priority, though both are ultimately important. Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Audit Priorities
Hi On 25/09/2023 17:33, Tim Düsterhus wrote: > Hi > > On 9/25/23 10:49, Derick Rethans wrote: >> So, if you can suggest an area where doing an external review would have >> high impact, please reply to this email. > > Some things from top of my head in arbitrary order. Not all of them are > necessarily important themselves per se, but rather intended to spark > additional thoughts. > > - Footguns in the default configuration / tunables / php.ini [1] This reminds me of something. There's an interesting paper about ReDoS resilience in different regex engines. Some programming languages, including PHP, are evaluated there and compared: https://www.usenix.org/system/files/sec22-turonova.pdf PHP has some configuration knobs for pcre (https://www.php.net/manual/en/pcre.configuration.php), not a lot to tune but maybe they can be? To be honest, I haven't looked much into this. > - MySQL Native Driver > - password_* [1] > - hash_equals() > - ext/json, specifically json_decode() > - The CSPRNG (ext/random/csprng.c) > - bin2hex, base64_encode [2] > - Open-ended: Misuse resistance of existing functions - Is it possible for a > user to not properly check a return value and would this result in harm (i.e. > should the function throw, but does not yet)? > > Best regards > Tim Düsterhus > > [1] These tie a little into my https://wiki.php.net/rfc/bcrypt_cost_2023 RFC, > which is not code but configuration. > [2] Should these be made constant-time / should constant-time implementations > always be available? See: https://github.com/paragonie/constant_time_encoding > Cheers Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
On Tue, 26 Sep 2023, Larry Garfield wrote: > ceil and floor should > always return ints, unconditionally, because that's literally what > their purpose is. But that RFC doesn't say that, which makes me quite > confused. They can't do that. ceil(2.4e102) can't be repesented as an integer. > Similarly, the BC shim would therefore be (float)ceil($x), not > ceil((float)$x), which... I don't think that would even do anything, > would it? (float) $int *could* also do something: $ php -dprecision=20 -r 'echo (float) 1152921504606846974;' 1152921504606846976 $ php -dprecision=20 -r 'var_dump(ceil((float) 1152921504606846974));' double(1152921504606846976) (see how the 74 changes into 76 at the end). Integers in the ranges LONG_MAX to 2^53, and -2^53 to LONG_MIN can't be represented as whole numbers as float, and some precision is lost. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC} Unbundle ext/imap, ext/pspell, and ext/oci8
Hi, after the initial introduction, here is the formal RFC to unbundle the imap, pspell, and oci8 extensions and move them to PECL, for PHP 8.4. https://wiki.php.net/rfc/unbundle_imap_pspell_oci8 cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4
On Fri, 15 Sep 2023, BohwaZ wrote: > > Considering the lack of updates from upstream as Derick mentioned, > > lack of OAuth support (which webklex/php-imap supports), and a > > somewhat lackluster documentation for ext-imap in php.net, I think > > unbundling ext-imap (along with the other extensions in the > > proposal) makes sense. > > I don't think that OAuth support is an argument, as most providers > don't support OAuth, so the imap package might still be relevant for > people who are not using Google. > > Also, the package currently works, IMAP is a stable protocol, maybe > this library is just stable? > > I'm not against the removal, but having to rely on user-space > libraries probably means we'll lose some performance over using the C > library. > > Also, some widely-used libraries like php-imap use it: > https://packagist.org/packages/php-imap/php-imap The ext/imap extension isn't going to disappear, it is not going be unbundled as we can not guarantee the underlaying library is maintained. Not only is it no longer maintained, the original purveyors have removed any mention of it from their website. For most people, there will be little change here. On Debian for example, "php-" is used for both bundled and PECL'ed extensions. > Personally I'm using curl for IMAP, as it is more widely available, > but I think removing php-imap might be a bit too early, except if > keeping it does require a lot of time / effort? Using Curl seems like a bad alternative, as it would likely have to open a connection for each action that you do. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
