7 ms·

> that shows many websites has not been updated to work with latest PHP 7+, which I'd say is quite shameful Speaking as an ex-hoster here who had to look after

> that shows many websites has not been updated to work with latest PHP 7+, which I'd say is quite shameful Speaking as an ex-hoster here who had to look after a fleet of shared servers running PHP (000's of sites) for 15 years, sadly life is not that simple in the trenches. The major problem with PHP is breaking changes. Even within the 5.x releases there were enough breaking changes such that upgrading from say 5.3 to 5.6 could break a site. The jump from 5.6 to 7.x has enough breaking changes to make you cry. I think there should have been a commitment to maintain 5.6 for the next ten years, if only for security fixes. Now I'm not suggesting that developers shouldn't go back and fix stuff that breaks because the PHP folks removed/altered that functionality (with the good intentions of encouraging more secure programming, for example), but there's a labour cost and someone needs to pay for that time. There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled. Sure register_globals is insecure but what we saw were folks adding the same functionality back, just google for "php emulate register_globals". And don't get me started about the annoyance that was removing mysql_* support. Those exact same insecure string concatenated queries are still being executed via mysqli_* and the PDO libraries. In my experience, binning mysql_* didn't make a damn bit of difference when it came to sql injection attacks. Don't get me wrong, I admire the efforts of the PHP core team, but they made a rod for our already sore support backs whenever a new release of PHP shipped because of some fairly unnecessary BC's.

buboard 8y ago
yeah the mysql_* function removal happened for no reason whatsoever. A library that did not need maintainance is something to keep , not throw away.
- nkozyra 8y ago
  Even though it had no paramaterized/prepared queries and made injection issues abundant?
  - buboard 8y ago
    not a fault of the library itself. also, mysqli_* has the same issue, was not removed
    - nkozyra 8y ago
      It doesn't matter whose fault it is; if it provides no mechanism for prepared queries, it should be replaced. mysqli_ has prepared queries, so it offers an immediate improvement.
      - creeble 8y ago
        Why couldn't the mysql_ library just have added prepared queries? I've never understood this (not a PHP programmer, just someone who has had to patch a dozen sites that were suddenly broken once).
        lugg 8y ago
        MySQL libraries are extensions. The mysqli library was likely a full rewrite in another extension. Extensions, at least that kind, at that time, didn't use/have namespaces. Keep in mind this is a legacy code base with a function called mysql_real_escape string, like if you're at that point you're so far past gone you've lost all hope.
        buboard 8y ago
        > like if you're at that point you're so far past gone you've lost all hope. for a 25 year library, thats not at all too bad. And even PHP developers admit that the lib was "not broken"
      - teh_klev 8y ago
        You missed my point. All developers did was replace their mysql_* calls with mysqli_* calls but skipped out on the parameterising step. Sure they're using a parameterised capable API, but they're not actually parameterising their queries. In the real world dropping the mysql_* API achieved next to bugger all, we still ended up with a bunch sites with exactly the same SQL injection vulns.
- leetbulb 8y ago
  This mysql extension was deprecated six years ago. It lacked support for many important features such as transactions, stored procedures, parameterization that were either often insecurely shoehorned or simply not capable. http://php.net/manual/en/mysqlinfo.api.choosing.php http://php.net/manual/en/mysqlinfo.api.choosing.php
  - teh_klev 8y ago
    Read my comment above where I explain why it was a pointless move: >Those exact same insecure string concatenated queries are still being executed via mysqli_ and the PDO libraries. In my experience, binning mysql_ didn't make a damn bit of difference when it came to sql injection attacks.
    - leetbulb 8y ago
      I don't care how safe you think your input validation is, concatenating strings and variables together should NEVER be done for SQL. Writing your own input validation for SQL is similar to "homebrew crypto." Even if it's mostly safe, it'll eventually bite you in the ass. You won't think of every possible attack vector. Same goes for shell, XSS, etc... In CTFs, you'd be surprised at some of the shit that you end up doing to exploit these types of vulnerabilities. Unlike ext/mysql, ext/mysqli and PDO both support server side prepared statements. If you don't utilize this properly, your argument is moot. Official discussion points here: https://wiki.php.net/rfc/mysql_deprecation#why https://wiki.php.net/rfc/mysql_deprecation#why The way I see it is new features, better practices, and greater security versus convenience. If the latter won, the former would need to be implemented on an ancient codebase, possibly opening up many new issues. If the former won and there's enough demand for ext/mysql, development may be continued by the community or at least shimmed on top of a proper extension or library. These decisions were being made while PHP was trying to gain traction in the "modern" web development community, making massive overall improvements leading to PHP 7+ due to pressure of Hack & HHVM, and doing a pretty damn good job with it. Sure it sucked to convert existing code, but looking back, I'm glad I did, even if ext/mysql were still available. Luckily some of the larger, more abstracted codebases I've had to convert meant simply writing and swapping out an adapter. Most of the codebases I see nowadays still utilizing ext/mysql were clearly destined to bitrot regardless and now have far more important problems to worry about because they weren't designed to be maintained this long or they've been poorly maintained from inception. Good riddance.
duiker101 8y ago
I had this problem just yesterday. A dev decided to update their XAMPP to a version that uses PHP7.3. Took us a while to understand why he was getting notices that no one else was getting. The compact function started printing notices of undefined variables since that version, it's a small thing, but I can see breaking a lot of stuff that is not expecting it.
phikai 8y ago
THIS... elebenty billion %. The breaking changes of PHP upgrades make the hosting life a nightmare. It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people.
- sowhatquestion 8y ago
  > It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people "Non-technical" people who don't plan for maintenance costs to their software (including maintenance to keep up with dependencies like PHP) don't get a ton of sympathy from me ¯\_(ツ)_/¯
  - deleted 8y ago
    [deleted]
DannyB2 8y ago
> The jump from 5.6 to 7.x has enough breaking changes to make you cry. It's not just PHP. But Python 2x / 3x as well. Just to point something out: this is one reason why Java is so well liked for large enterprise code bases. They have been religious about backward compatibility in new versions. A 2nd principle I would advocate is that if there must be a breaking change, it should be caught at compile time, not at run time. The project should fail to build, and the errors point you to exactly where the source code problems are. Other language systems would do well to embrace backward compatibility and build time errors over run time errors. IMO.
- consp 8y ago
  > ... But Python 2x / 3x as well. That was one of the lowest effort upgrades I ever did for my company (backend services, no front end websites). One of the other reasons Java is popular in big companies is the low effort it requires to find people who can work with it.
  - fucking_tragedy 8y ago
    > That was one of the lowest effort upgrades I ever did for my company (backend services, no front end websites). If your application does a lot of ASCII/unicode/raw string and byte manipulation, the transition from Python 2 to 3 can be very cumbersome.
- teh_klev 8y ago
  > But Python 2x / 3x as well. But at least the python folks provided some tooling to bridge the gap between v2 and v3 such as backporting features from python 3. Also minor version updates generally don't break whole codebases. Apropos Java backwards compatibility, Microsoft has been pretty good at ensuring strong backwards compatibility with .NET code. I've seen .NET 1.0 source compile and run just fine on .NET 4. Hell I've even witnessed .NET 1.0 binaries run just fine without recompilation in newer .NET environments. Sure there's breaking differences between .NET Standard and .NET Core but they're two different products and that was made pretty apparent from the get-go.
- kevin_thibedeau 8y ago
wvenable 8y ago
> There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled. It was for years! They deprecated the feature. It was default disabled in php.ini. And now, as you said, if you really still need it you can code it yourself (I had to). > And don't get me started about the annoyance that was removing mysql_* support. I'm pretty sure that library isn't supported by MySQL server anymore (it's their library) so that's why it was removed. You can even use it to connect to newer versions of MySQL as the protocol changed.

buboard 8y ago

yeah the mysql_* function removal happened for no reason whatsoever. A library that did not need maintainance is something to keep , not throw away.

nkozyra 8y ago
Even though it had no paramaterized/prepared queries and made injection issues abundant?
- buboard 8y ago
  not a fault of the library itself. also, mysqli_* has the same issue, was not removed
  - nkozyra 8y ago
    It doesn't matter whose fault it is; if it provides no mechanism for prepared queries, it should be replaced. mysqli_ has prepared queries, so it offers an immediate improvement.
    - creeble 8y ago
      Why couldn't the mysql_ library just have added prepared queries? I've never understood this (not a PHP programmer, just someone who has had to patch a dozen sites that were suddenly broken once).
      - lugg 8y ago
        MySQL libraries are extensions. The mysqli library was likely a full rewrite in another extension. Extensions, at least that kind, at that time, didn't use/have namespaces. Keep in mind this is a legacy code base with a function called mysql_real_escape string, like if you're at that point you're so far past gone you've lost all hope.
        buboard 8y ago
        > like if you're at that point you're so far past gone you've lost all hope. for a 25 year library, thats not at all too bad. And even PHP developers admit that the lib was "not broken"
    - teh_klev 8y ago
      You missed my point. All developers did was replace their mysql_* calls with mysqli_* calls but skipped out on the parameterising step. Sure they're using a parameterised capable API, but they're not actually parameterising their queries. In the real world dropping the mysql_* API achieved next to bugger all, we still ended up with a bunch sites with exactly the same SQL injection vulns.
leetbulb 8y ago
This mysql extension was deprecated six years ago. It lacked support for many important features such as transactions, stored procedures, parameterization that were either often insecurely shoehorned or simply not capable. http://php.net/manual/en/mysqlinfo.api.choosing.php http://php.net/manual/en/mysqlinfo.api.choosing.php
- teh_klev 8y ago
  Read my comment above where I explain why it was a pointless move: >Those exact same insecure string concatenated queries are still being executed via mysqli_ and the PDO libraries. In my experience, binning mysql_ didn't make a damn bit of difference when it came to sql injection attacks.
  - leetbulb 8y ago
    I don't care how safe you think your input validation is, concatenating strings and variables together should NEVER be done for SQL. Writing your own input validation for SQL is similar to "homebrew crypto." Even if it's mostly safe, it'll eventually bite you in the ass. You won't think of every possible attack vector. Same goes for shell, XSS, etc... In CTFs, you'd be surprised at some of the shit that you end up doing to exploit these types of vulnerabilities. Unlike ext/mysql, ext/mysqli and PDO both support server side prepared statements. If you don't utilize this properly, your argument is moot. Official discussion points here: https://wiki.php.net/rfc/mysql_deprecation#why https://wiki.php.net/rfc/mysql_deprecation#why The way I see it is new features, better practices, and greater security versus convenience. If the latter won, the former would need to be implemented on an ancient codebase, possibly opening up many new issues. If the former won and there's enough demand for ext/mysql, development may be continued by the community or at least shimmed on top of a proper extension or library. These decisions were being made while PHP was trying to gain traction in the "modern" web development community, making massive overall improvements leading to PHP 7+ due to pressure of Hack & HHVM, and doing a pretty damn good job with it. Sure it sucked to convert existing code, but looking back, I'm glad I did, even if ext/mysql were still available. Luckily some of the larger, more abstracted codebases I've had to convert meant simply writing and swapping out an adapter. Most of the codebases I see nowadays still utilizing ext/mysql were clearly destined to bitrot regardless and now have far more important problems to worry about because they weren't designed to be maintained this long or they've been poorly maintained from inception. Good riddance.

duiker101 8y ago

I had this problem just yesterday. A dev decided to update their XAMPP to a version that uses PHP7.3. Took us a while to understand why he was getting notices that no one else was getting. The compact function started printing notices of undefined variables since that version, it's a small thing, but I can see breaking a lot of stuff that is not expecting it.

phikai 8y ago

THIS... elebenty billion %. The breaking changes of PHP upgrades make the hosting life a nightmare. It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people.

sowhatquestion 8y ago
> It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people "Non-technical" people who don't plan for maintenance costs to their software (including maintenance to keep up with dependencies like PHP) don't get a ton of sympathy from me ¯\_(ツ)_/¯
- deleted 8y ago
  [deleted]

DannyB2 8y ago

> The jump from 5.6 to 7.x has enough breaking changes to make you cry. It's not just PHP. But Python 2x / 3x as well. Just to point something out: this is one reason why Java is so well liked for large enterprise code bases. They have been religious about backward compatibility in new versions. A 2nd principle I would advocate is that if there must be a breaking change, it should be caught at compile time, not at run time. The project should fail to build, and the errors point you to exactly where the source code problems are. Other language systems would do well to embrace backward compatibility and build time errors over run time errors. IMO.

consp 8y ago
> ... But Python 2x / 3x as well. That was one of the lowest effort upgrades I ever did for my company (backend services, no front end websites). One of the other reasons Java is popular in big companies is the low effort it requires to find people who can work with it.
- fucking_tragedy 8y ago
  > That was one of the lowest effort upgrades I ever did for my company (backend services, no front end websites). If your application does a lot of ASCII/unicode/raw string and byte manipulation, the transition from Python 2 to 3 can be very cumbersome.
teh_klev 8y ago
> But Python 2x / 3x as well. But at least the python folks provided some tooling to bridge the gap between v2 and v3 such as backporting features from python 3. Also minor version updates generally don't break whole codebases. Apropos Java backwards compatibility, Microsoft has been pretty good at ensuring strong backwards compatibility with .NET code. I've seen .NET 1.0 source compile and run just fine on .NET 4. Hell I've even witnessed .NET 1.0 binaries run just fine without recompilation in newer .NET environments. Sure there's breaking differences between .NET Standard and .NET Core but they're two different products and that was made pretty apparent from the get-go.
kevin_thibedeau 8y ago

wvenable 8y ago

> There's also functionality in PHP that shouldn't have been removed (register_globals) but should have been defaulted to disabled. It was for years! They deprecated the feature. It was default disabled in php.ini. And now, as you said, if you really still need it you can code it yourself (I had to). > And don't get me started about the annoyance that was removing mysql_* support. I'm pretty sure that library isn't supported by MySQL server anymore (it's their library) so that's why it was removed. You can even use it to connect to newer versions of MySQL as the protocol changed.