On Wed, Aug 14, 2019 at 10:49 AM Robert Korulczyk <rob...@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. > >> `<? $dbPasword = 'my$ecret' ?>` 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 `<?php`, so it will work as expected). And exposing DB > 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 chasepee...@gmail.com
