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

This is only part of a thread. view whole thread
  106593
August 14, 2019 10:23 peterkokot@gmail.com (Peter Kokot)
On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, <r@roze.lv> wrote:

> > It is surprising how thing that is considered by one to be a security > risk, is treated > > as nothing relevant by others. This dichotomy is quite disturbing - in > what case > > removing security risk is "no real gain"? > > It's questionable that a misconfigured environment is a "security" risk > caused by language rather than ignorance of the administrator. > > On that matter you could ask why are all the exec/passthru/proc_open etc > functions/features are allowed by default while every other guide on > hardening web suggests those to be disabled (added to disable_functions)? > I would bet there have been a lot more (actual) security breaches because > of unsanitized/unescaped parameters to those. > > Just to repeat some other people - there are a lot other things to work on > than this. > > rr > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Appologies if these short tags are bumped so many times and cause so much issues but we are at the very starting discussions of PHP 8 also. Major version, where breaking thing was supposed to be possible. So that is one of the reasons why this and similar cleanups are mentioned in the first place. With closing the door to even talk and work on cleanups, or being ashamed of it, or bully others because they want to have a better structure with using PHP 8+, nothing good can come out of it.
> > >
  106598
August 14, 2019 11:01 hisamsonolu@gmail.com (Olumide Samson)
On Wed, Aug 14, 2019, 11:24 AM Peter Kokot <peterkokot@gmail.com> wrote:

> On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, <r@roze.lv> wrote: > > > > It is surprising how thing that is considered by one to be a security > > risk, is treated > > > as nothing relevant by others. This dichotomy is quite disturbing - in > > what case > > > removing security risk is "no real gain"? > > > > It's questionable that a misconfigured environment is a "security" risk > > caused by language rather than ignorance of the administrator. > > > > On that matter you could ask why are all the exec/passthru/proc_open etc > > functions/features are allowed by default while every other guide on > > hardening web suggests those to be disabled (added to disable_functions)? > > I would bet there have been a lot more (actual) security breaches because > > of unsanitized/unescaped parameters to those. > > > > Just to repeat some other people - there are a lot other things to work > on > > than this. > > > > rr > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > Appologies if these short tags are bumped so many times and cause so much > issues but we are at the very starting discussions of PHP 8 also. Major > version, where breaking thing was supposed to be possible. So that is one > of the reasons why this and similar cleanups are mentioned in the first > place. With closing the door to even talk and work on cleanups, or being > ashamed of it, or bully others because they want to have a better structure > with using PHP 8+, nothing good can come out of it. > > > > > > > > I'm with you on this PHP 8 argument.
I think many of this popular languages that's making my PHP professional coding look like kids play make sure their major version shake up many old things, to cleanup old things that's either better not released or would cause some developers to write environment-tied programs. Since we don't have any good cause to leave it be, let it go. Let the user land developers see PHP as a major language they are hoping for. Currently, it's easy to learn, use, break or make. Let them see the intern devs are strict and mature enough to break things when needed and when possible. Break it off if it's not useful or would allow the possibility to write environment tied code(where short tag is not a general idea) and what are we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let the world wow at the internals courage, focus and super ability to implement what's needed. Why wait for a time, when we have little time? Should we wait for cleanups until PHP 9 or PHP 10? Im sure javascript would have moved on around that time as the same language for web, mobile and desktop application, while PHP a major language still keep in doing its stuff at the server side(and the user land get booed as boring programmer who would have to learn multiple languages to get a desktop, mobile and web application designed). Please,clean up.
>
  106602
August 14, 2019 13:31 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 14, 2019 at 7:03 AM Olumide Samson <hisamsonolu@gmail.com>
wrote:

> On Wed, Aug 14, 2019, 11:24 AM Peter Kokot <peterkokot@gmail.com> wrote: > > > On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, <r@roze.lv> wrote: > > > > > > It is surprising how thing that is considered by one to be a security > > > risk, is treated > > > > as nothing relevant by others. This dichotomy is quite disturbing - > in > > > what case > > > > removing security risk is "no real gain"? > > > > > > It's questionable that a misconfigured environment is a "security" risk > > > caused by language rather than ignorance of the administrator. > > > > > > On that matter you could ask why are all the exec/passthru/proc_open > etc > > > functions/features are allowed by default while every other guide on > > > hardening web suggests those to be disabled (added to > disable_functions)? > > > I would bet there have been a lot more (actual) security breaches > because > > > of unsanitized/unescaped parameters to those. > > > > > > Just to repeat some other people - there are a lot other things to work > > on > > > than this. > > > > > > rr > > > > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > Appologies if these short tags are bumped so many times and cause so much > > issues but we are at the very starting discussions of PHP 8 also. Major > > version, where breaking thing was supposed to be possible. So that is one > > of the reasons why this and similar cleanups are mentioned in the first > > place. With closing the door to even talk and work on cleanups, or being > > ashamed of it, or bully others because they want to have a better > structure > > with using PHP 8+, nothing good can come out of it. > > > > > > > > > > > > > > I'm with you on this PHP 8 argument. > I think many of this popular languages that's making my PHP professional > coding look like kids play make sure their major version shake up many old > things, to cleanup old things that's either better not released or would > cause some developers to write environment-tied programs. > Since we don't have any good cause to leave it be, let it go. > > Let the user land developers see PHP as a major language they are hoping > for. > > Currently, it's easy to learn, use, break or make. > Let them see the intern devs are strict and mature enough to break things > when needed and when possible. > > Break it off if it's not useful or would allow the possibility to write > environment tied code(where short tag is not a general idea) and what are > we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let > the world wow at the internals courage, focus and super ability to > implement what's needed. Why wait for a time, when we have little time? > Should we wait for cleanups until PHP 9 or PHP 10? > Im sure javascript would have moved on around that time as the same > language for web, mobile and desktop application, while PHP a major > language still keep in doing its stuff at the server side(and the user land > get booed as boring programmer who would have to learn multiple languages > to get a desktop, mobile and web application designed). > > Please,clean up. > > > >
The "shake-ups" that will draw people to PHP are the new features, the majority of which don't require BC breaks and were listed earlier in this thread. Go find a group of anti-PHP developers. Tell them how wonderful PHP 9 is going to be. When they ask why, tell them "We've got rid of short tags!" and see how they react. Now, find another group of anti-PHP developers. Tell them how wonderful PHP 9 is going to be. Tell them it will have generics, enums, union types, and JIT. Also mention that short tags will still be allowed. See how they react. They might not really care, and still not like PHP, but I can guarantee you it won't be because short tags still exist. -- Chase Peeler chasepeeler@gmail.com