Re: [PHP-DEV] Replace libjpeg with libjpeg-turbo for PHP 8.1+ on Windows
On 09.05.2021 at 17:45, Dan Ackroyd wrote: > On Sun, 9 May 2021 at 16:04, Christoph M. Becker wrote: >> >> I suggest to replace libjpeg[1] with libjpeg-turbo[2] for future PHP >> releases on Windows, starting with PHP 8.1. >> >> Thoughts? Objections? > > So the ABI break would only affect people who have some C code that is > dependent on the new version of the data structure? Right. And I doubt that this is even used at all, since it is not compatible with common decoders. > If that's the case, then it sounds like either they can compile their > own version of PHP for Windows, or complain about it during the > release candidate process. > > But switching to the faster library sounds good. Great. I'm going to roll out libjpeg-turbo for php-src/master builds right away. Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] is_literal
Injection Vulnerabilities remain at the top of the OWASP "Top 10 Web Application Security Risks". It’s important to remember that Injection Vulnerabilities don't just affect the developer, but rather the data of potentially thousands of people using the website/system. These can even occur when using libraries. Take this example from CakePHP, where the developer has dangerously included user data into the SQL: $users->find()->where(['age >= ' . $_GET['age']]); By distinguishing strings from a trusted developer, from strings that may be attacker controlled, libraries can ensure values that go directly into the SQL, HTML, CLI, etc have not been "Injected" with user data. PHP is now lagging behind other languages, where Java and Go can already test for developer defined strings (it's also being implemented in JavaScript). is_literal() is a simple and minor change that simply utilises a currently unused flag on strings to mark whether the string was written by the developer. It requires no rewriting of code by the developer to work, no grand visionary overhaul of the PHP language, with only a 0.43% difference in speed that is too small to measure with normal internet/database variability. It’s just a basic but effective way of being able to warn about and locate Injection Vulnerabilities (and therefore providing a way for libraries to directly educate developers). The vote for this RFC ends on Monday the 19th of July, 7:30pm UK time and 6:30pm UTC, and needs your support. https://wiki.php.net/rfc/is_literal The following link provides more examples of these mistakes, based on code I’ve found on production servers. They show how similar they are to the examples found in the libraries official documentation, and how easy it is for a developer to make a small tweak that ends up being very dangerous: https://github.com/craigfrancis/php-is-literal-rfc/blob/main/justification/mistakes.php I have created 3 example libraries you can experiment with, to see what is_literal() can do: https://github.com/craigfrancis/php-is-literal-rfc/tree/main/examples I'm happy to take questions on and off list. Vote ends on Monday the 19th of July, 7:30pm UK time and 6:30pm UTC. https://wiki.php.net/rfc/is_literal Thanks, Craig >
[PHP-DEV] Re: [VOTE] Deprecations for PHP 8.1
On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov wrote: > Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. > The vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. > Here are the results of the vote. The following deprecations have been declined: * get_class(), get_parent_class() and get_called_class() without argument: 21 in favor, 21 against * t fopen mode: 13 in favor, 17 against The following deprecations have been accepted: * date_sunrise() and date_sunset(): 51 in favor, 0 against * key(), current(), next(), prev(), and reset() on objects: 48 in favor, 0 against * mb_check_encoding() without argument: 44 in favor, 0 against * FILE_BINARY and FILE_TEXT constants: 42 in favor, 1 against * Passing bool for $value argument of IntlCalendar::roll(): 38 in favor, 0 against * Accessing static members on traits: 40 in favor, 0 against * strptime(): 35 in favor, 0 against * strftime() and gmtstrftime(): 29 in favor, 9 against * mhash*() function family: 38 in favor, 0 against * ctype_*() function family accepts int parameters: 34 in favor, 2 against * Return by reference with void type: 39 in favor, 1 against * NIL constant defined by the IMAP extension: 35 in favor, 0 against * Calling overloaded pgsql functions without the connection argument: 36 in favor, 1 against * $num_points parameter of image(open|filled)polygon: 20 in favor, 9 against * mysqli::init(): 34 in favor, 0 against * filter.default ini setting: 28 in favor, 4 against * auto_detect_line_endings ini setting: 38 in favor, 0 against * ssl_method option to SoapClient constructor: 25 in favor, 1 against * FILTER_SANITIZE_STRING: 36 in favor, 0 against, * oci8.old_oci_close_semantics ini setting: 27 in favor, 0 against * odbc_result_all(): 34 in favor, 0 against Regards, Nikita
[PHP-DEV] Re: [Vote] New in initializers
On Wed, Jun 30, 2021 at 9:55 AM Nikita Popov wrote: > Hi internals, > > I've opened voting on https://wiki.php.net/rfc/new_in_initializers. > Voting will close on 2021-07-14. > > Note that relative to the original RFC, new support is limited to > parameter default values, attribute arguments, static variable initializers > and global constant initializers, and not supported in property > initializers and class constant initializers. The discussion thread > https://externals.io/message/113347 has some extensive information on how > we got here. > This RFC has been accepted with 43 votes in favor and 2 against. Regards, Nikita
