RE: [PHP-DEV] Deprecate PHP's short open tags, again

This is only part of a thread. view whole thread
  106603
August 14, 2019 13:50 r@roze.lv ("Reinis Rozitis")
> Please, let's keep this discussion at some level of sanity... You basically need > stick to static HTML if you're considering possibility of such exec() usage as a > security issue.
This discussion has gone out of sanity levels the moment people started to state that short tags is one (of the many) things PHP has why new programmers and companies don't pick the language or why colleagues laugh at you and is a blocker of new bright future etc. and now in this moment this is a do or die situation otherways next year everyone will be writing in javascript.
> 1. exec-like functions have their purpose without any straight-forward alternative, while ` Except there are 4-5 functions which do the same not to mention `` backtick syntax (can't there be an accident mixing those with single quotes?).
> `` is intended usage of short open tags.
On this I could also say that recommendations are to store all credentials outside webroot, but again it also qualify as something different than by accident generated code in IDE, just to show that the "security issue" can be stretched however you like.
> You basically need stick to static HTML
Maybe. But let's end at this .. rr
  106604
August 14, 2019 14:49 robert@korulczyk.pl (Robert Korulczyk)
> This discussion has gone out of sanity levels the moment people started to state that short tags is one (of the many) > things PHP has why new programmers and companies don't pick the language or why colleagues laugh at you and is a > blocker of new bright future etc. and now in this moment this is a do or die situation otherways next year everyone > will be writing in javascript.
No one said that (except you). But current reaction for this RFC could be depressing. I'm using PHP for quite a long time and I really hoped that someday we'll be able to get rid of all (or at least the most of them) the traps and annoying little things from the old days. That doesn't sound realistic anymore...
> Except there are 4-5 functions which do the same not to mention `` backtick syntax (can't there be an accident mixing those with single quotes?).
I was talking about all these functions that allows to execute shell commands. What is the point of disabling only one of them? I thought that the problem is in functionality, not in the name :P
>> `` is intended usage of short open tags. > > On this I could also say that recommendations are to store all credentials outside webroot,
I'm afraid you don't understand the problem. Having such code outside of webroot does not help you much if this file will be included from another file (which uses `
  106607
August 14, 2019 15:37 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 14, 2019 at 10:49 AM Robert Korulczyk <robert@korulczyk.pl>
wrote:

> > This discussion has gone out of sanity levels the moment people started > to state that short tags is one (of the many) > > things PHP has why new programmers and companies don't pick the language > or why colleagues laugh at you and is a > > blocker of new bright future etc. and now in this moment this is a do or > die situation otherways next year everyone > > will be writing in javascript. > > No one said that (except you). > > While possibly a bit hyperbolic, most of the arguments basically come off that way to me as well. I've definitely viewed most of what you've said in
that manner.
> But current reaction for this RFC could be depressing. I'm using PHP for > quite a long time and I really hoped that someday we'll be able to get rid > of > all (or at least the most of them) the traps and annoying little things > from the old days. That doesn't sound realistic anymore... > > This is exactly what we're talking about. You act as if leaving short tags in PHP means nothing will ever get cleaned up. That there is absolutely no
reason at all we might want to consider leaving them, so, the fact that we are is just a signal that no one is willing to entertain the idea of BC breaks for anything ever.
> > > Except there are 4-5 functions which do the same not to mention `` > backtick syntax (can't there be an accident mixing those with single > quotes?). > > I was talking about all these functions that allows to execute shell > commands. What is the point of disabling only one of them? I thought that > the > problem is in functionality, not in the name :P > > Or, maybe, it's just that the negative consequences of removing those functions doesn't justify the positives that would be gained? That's the
whole argument with short tags. It's not "Short tags are wonderful!" or "There is absolutely NOTHING bad about short tags and how they are currently handled." We've just been saying that while there are negatives, they are negatives that have existed for 20 years without causing large scale issues. The issues they cause do not justify removing them and the impact it will have on existing developers and code bases. It causes a large amount of difficulty for many people to upgrade while only solving a possible security issue that is actually pretty easy to avoid. Honestly, while I didn't have a vote, if the RFC didn't include language about actually removing short tag support in PHP 9, I would have encouraged people to support it. I have no issues with helping push people towards not using short tags, and then at some point in the future discussing whether to remove support or not. In the end, what I see is one side (those for keeping short tag support) readily admitting that there are issues with short tags, but they aren't outweighed by the negatives. I see the other side (those for removing short tag support) acting as if there were absolutely no negatives at all to removing them. You even said exactly that: "Since we don't have any good cause to leave it be, let it go." They also inflate the issues with short tags to hyperbolic levels, making them into a huge security implication, the driving force behind anti-PHP sentiment, and the barrier to new developers picking up the language. That makes it impossible to have a reasoned discussion on the argument. It's like one side is saying "I know fire is dangerous, but I think it's a good idea to have some matches handy just in case." And the other side saying "No, if we have matches no one will ever come to our house and all of our neighbors will laugh at us and we'll almost definitely burn the house down." Even though you've had matches in the house for the last 20 years without any issues.
> >> `` is intended usage of short open tags. > > > > On this I could also say that recommendations are to store all > credentials outside webroot, > > > I'm afraid you don't understand the problem. Having such code outside of > webroot does not help you much if this file will be included from another > file (which uses ` password is just the simplest example - single non-working `if` can lead to > a > wide range of bugs with serious consequences, far beyond code leak. > > What about the display_errors ini directive? That seems like a security risk as well, since error messages can contain sensitive information. I
know keeping/removing it isn't mutually exclusive with keeping/removing short tags. I'm just curious why it's never mentioned by anyone that suddenly is so concerned about the security implications of short tags.
> > > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  106611
August 14, 2019 16:22 robert@korulczyk.pl (Robert Korulczyk)
> While possibly a bit hyperbolic, most of the arguments basically come off that way to me as well. I've definitely viewed most of what you've said in > that manner.
I guess we're in some kind of limbo where half of the people do not consider problems which short open tags create as serious, and other half does not consider BC break implications as serious. I already migrated some quite big legacy apps from `
  106612
August 14, 2019 17:00 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 14, 2019 at 12:22 PM Robert Korulczyk <robert@korulczyk.pl>
wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come > off that way to me as well. I've definitely viewed most of what you've said > in > > that manner. > > I guess we're in some kind of limbo where half of the people do not > consider problems which short open tags create as serious, and other half > does not > consider BC break implications as serious. > No, we're not. Only people that are in favor of removing short tags seem to
be making this RFC a referendum on BC breaks in general. We understand there is a security risk. As others have pointed out, it's a rather minor one. Code gets deployed with short tags onto a server that has short tag support turned off. The solution is to turn short tags back on. It's a setting that can be turned on/off at any level, so, just throw it in your ..htaccess file. If you use windows and IIS like me, you can set it in your registry. Not ideal, but, it works. If there was no way to quickly enable short tag support, the discussion might be different. Since there is, the security implications, while they exist, are mitigated. It's further mitigated by the fact that almost everyone writing portable code is not using short tags to begin with. This means the odds of me downloading a 3rd party library that uses short tags is pretty slim. If I actually do some due diligence (look at the source code, stick to something actively maintained, something with good reviews, etc) it's even slimmer. If it's code I'm writing myself, then, I should no better than to write code with short tags if I'm going to deploy it to a server that doesn't support them (or that I don't have control over). As Zeev has mentioned many times, in retrospect, short tags probably should have never been supported. If they never had been supported, then there wouldn't be any case for adding support for them now. That doesn't change the fact that they have been support for 20 years, and removing support for them now has huge implications for a lot of non-portable legacy code.That is compared with a security issue, that while it does exist, is very unlikely to occur for anyone using a modicum of common sense, and can easily be resolved if it does.
> I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal > with. So for me "it will be so hard to upgrade" arguments are also > exaggerated, and that's why I'm concerned about future BC breaks - if such > simple > change encounters such fierce resistance, then what kind of BC break can > be accepted? > > Good for you! Come take a stab at my legacy project. It's horrendous. We have some files where using PhpStorm's automatic formatting actually caused
stuff to break. So, you can see why I might be a little reticent to depend on an automated tool to change my php tags. I'll let you start with a 12k+ line file of spaghetti code. This file contains a lot of functions (not OO) used across the legacy parts of the application. As such, it's included at the top of pretty much every PHP page. So, make sure you don't leave a typo, because it'll break the entire application! While you are at it, you can explain to my executive team (I don't work for a software company) why it's worth putting in the time to modify all these "don't touch unless it's an emergency" legacy files to upgrade PHP when the current version seems to be working fine from their perspective. That's another difference I've seen from the two sides of the argument. Those in favor of removing them usually say things like "It doesn't seem like a big deal to me" or "I converted a project and it was really easy" or "People shouldn't be using short tags anyway, so who cares." While those against removing them usually say things like "I can see how this could be a huge problem for a large number of users" or "This could definitely block a lot of people from upgrading in a timely manner." I'm one of the few people I've seen that is against removing short tags AND has provided examples in their own code bases of how it will impact them in a negative way. Most of those against it have based their opinion on knowing that others will be negatively impacted by this, even if they personally won't. Honestly, if it was just my code that was the concern, I wouldn't be as vocal. I can suck it up and fix things. I can cut through the red tape and get it done at some point so we can upgrade. I'm vocal on this because I know there are other developers out there dealing with a legacy code base like mine, if not worse, that might not be able to just bite the bullet and get it done.
> Regards, > Robert Korulczyk >
-- Chase Peeler chasepeeler@gmail.com
  106616
August 14, 2019 19:56 robert@korulczyk.pl (Robert Korulczyk)
> Good for you! Come take a stab at my legacy project. It's horrendous. We have some files where using PhpStorm's automatic formatting actually caused > stuff to break. So, you can see why I might be a little reticent to depend on an automated tool to change my php tags. I'll let you start with a 12k+ > line file of spaghetti code. This file contains a lot of functions (not OO) used across the legacy parts of the application. As such, it's included at > the top of pretty much every PHP page. So, make sure you don't leave a typo, because it'll break the entire application! 
I know how painful could be maintaining legacy code, but did you tried to run php-cs-fixer against this 12k+ file with PHP-spaghetti and report some actual issues? You're spending time theorizing how automated tool can break your legacy code, but it would be far more productive if you spend it on actual tests - this would give us very valuable insights how serious this problem is. Right now these are nothing more than *speculations* based on usage of *completely different tool* for *completely different task*. Please, don't treat it as some hard argument.
> While you are at it, you can explain to my executive team (I don't work for a software company) why it's worth putting in the time to modify all > these "don't touch unless it's an emergency" legacy files to upgrade PHP when the current version seems to be working fine from their perspective.
Sure. It would be something like: "Hey, it's *emergency*!" ;)
> That's another difference I've seen from the two sides of the argument. Those in favor of removing them usually say things like "It doesn't seem like > a big deal to me" or "I converted a project and it was really easy" or "People shouldn't be using short tags anyway, so who cares." While those > against removing them usually say things like "I can see how this could be a huge problem for a large number of users" or "This could definitely block > a lot of people from upgrading in a timely manner."
This is one side of the coin. I'll show you another: I gave a real-world example that short open tag could lead to serious fuckup and be undetected for quite a long time. I also gave an example of how easy is to accidentally introduce short open tags in your code. There are other people who also treats short open tags as dangerous feature and security issue. Despite this, I can read multiple times that "short open tags are no-issue" or "there is no gain in removing short open tags". In counterargument for this RFC you can read that "Deprecating short tags, as illustrated in this counterargument, brings us *virtually no value at all*.". There is no difference between both "camps" - both are focusing on their perspective and their arguments, while underestimating problems and arguments of other "camp". For you existence of short open tags is minor issue, for me migrating to `
  106613
August 14, 2019 17:01 hisamsonolu@gmail.com (Olumide Samson)
On Wed, Aug 14, 2019, 5:23 PM Robert Korulczyk <robert@korulczyk.pl> wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come > off that way to me as well. I've definitely viewed most of what you've said > in > > that manner. > > I guess we're in some kind of limbo where half of the people do not > consider problems which short open tags create as serious, and other half > does not > consider BC break implications as serious. > I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal > with.
So for me "it will be so hard to upgrade" arguments are also exaggerated,
> and that's why I'm concerned about future BC breaks - if such simple > change encounters such fierce resistance, then what kind of BC break can > be accepted? > This was exactly my reason for participating in this discussion, if such
simple BC break encounters fierce and lengthy-weighted resistance, I'm not sure there will ever be a BC break, only additions without a necessary cleanup. That's just like, there's a precedent to resist all kinds of BC break simply because there's no positive impact on the change. Millions of code can be migrated through many existing libraries in short time frame to comply with the short tag depreciation. I think the resistance is actually the reason this discussion(thread) gets this lengthy. At the end of all, we either have it or leave it. Happy coding.
> > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  106615
August 14, 2019 18:19 claude.pache@gmail.com (Claude Pache)
> Le 14 août 2019 à 19:01, Olumide Samson <hisamsonolu@gmail.com> a écrit : > > This was exactly my reason for participating in this discussion, if such > simple BC break encounters fierce and lengthy-weighted resistance, I'm not > sure there will ever be a BC break, only additions without a necessary > cleanup. > > That's just like, there's a precedent to resist all kinds of BC break > simply because there's no positive impact on the change.
No, BC breaks and cleanups have been regularly implemented in the past, and that will continue. Two recent examples among several others: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase <https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase> https://wiki.php.net/rfc/ternary_associativity <https://wiki.php.net/rfc/ternary_associativity> About short-open tags. Many people thought that this particular BC break or cleanup was not useful enough. That’s all. —Claude