Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [VOTE] Deprecate PHP's short open tags, again »

[RFC] [VOTE] Deprecate PHP's short open tags, again

php.internals

Girgias

7 years ago
The voting for the "Deprecate short open tags, again" [1] RFC has begun. It is expected to last two (2) weeks until 2019-08-20. A counter argument to this RFC is available at https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags Best regards George P. Banyard [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2

Chase Peeler

7 years ago
I'm not a voter, but, I have a question. If this fails, does that mean the original RFC that passed is still in effect? If I did have a vote, I would be against this RFC for the reasons laid out by Zeev in the counter argument. However, I feel the negative impacts of possible code leaks that will be caused by the original RFC are even worse. If I did have a vote, I might feel forced to vote for this. At least with this RFC we wouldn't really see any of the other negative impacts until PHP 9, given us time to revisit and possibly reverse that part of this RFC. On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> wrote:
> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >
-- Chase Peeler chasepeeler@gmail.com

Rowan Collins

7 years ago
On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote:
> I'm not a voter, but, I have a question. If this fails, does that mean the > original RFC that passed is still in effect? >
Yes, this is really ambiguous, and risks the situation being even more confusing than it was before. The "No" column on this RFC already includes people who voted "Yes" on the previous version; is this an indication that they have changed their mind about removing short tags, or that they prefer the original proposal? I think we urgently need to clarify this, and may need to reset the vote with one or more clearer questions. Regards,
-- Rowan Collins [IMSoP]

Girgias

7 years ago
On Tue, 6 Aug 2019 at 19:12, Rowan Collins <rowan.collins@gmail.com> wrote:
> On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: > > > I'm not a voter, but, I have a question. If this fails, does that mean > the > > original RFC that passed is still in effect? > > > > > Yes, this is really ambiguous, and risks the situation being even more > confusing than it was before. > > The "No" column on this RFC already includes people who voted "Yes" on the > previous version; is this an indication that they have changed their mind > about removing short tags, or that they prefer the original proposal? > > I think we urgently need to clarify this, and may need to reset the vote > with one or more clearer questions. > > Regards, > -- > Rowan Collins > [IMSoP]
This RFC supersedes the previous one as stated in the the RFC itself : " This RFC supersedes the previous one and proposes a different deprecation approach." meaning that the previous one is void. I don't know why this is ambiguous and needs to be said once again. Best regards George P. Banyard

Peter Kokot

7 years ago
Hello, On Tue, 6 Aug 2019 at 19:19, G. P. B. <george.banyard@gmail.com> wrote:
> > On Tue, 6 Aug 2019 at 19:12, Rowan Collins <rowan.collins@gmail.com> wrote: > > > On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > > I'm not a voter, but, I have a question. If this fails, does that mean > > the > > > original RFC that passed is still in effect? > > > > > > > > > Yes, this is really ambiguous, and risks the situation being even more > > confusing than it was before. > > > > The "No" column on this RFC already includes people who voted "Yes" on the > > previous version; is this an indication that they have changed their mind > > about removing short tags, or that they prefer the original proposal? > > > > I think we urgently need to clarify this, and may need to reset the vote > > with one or more clearer questions. > > > > Regards, > > -- > > Rowan Collins > > [IMSoP] > > > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. > > Best regards > > George P. Banyard
Thank you for clarification. From what I understand it is the case where "no" means a status quo and no agreements has been reached on the original RFC. Since the original RFC has been vetoed and so much energy was invested from Zeev and some others commentators then I guess the RFCs fail and we will have two types of opening tags in PHP for ever. Otherwise, as described, yes.
-- Peter Kokot

Chase Peeler

7 years ago
On Tue, Aug 6, 2019 at 1:19 PM G. P. B. <george.banyard@gmail.com> wrote:
> > > > On Tue, 6 Aug 2019 at 19:12, Rowan Collins <rowan.collins@gmail.com> > wrote: > >> On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: >> >> > I'm not a voter, but, I have a question. If this fails, does that mean >> the >> > original RFC that passed is still in effect? >> > >> >> >> Yes, this is really ambiguous, and risks the situation being even more >> confusing than it was before. >> >> The "No" column on this RFC already includes people who voted "Yes" on the >> previous version; is this an indication that they have changed their mind >> about removing short tags, or that they prefer the original proposal? >> >> I think we urgently need to clarify this, and may need to reset the vote >> with one or more clearer questions. >> >> Regards, >> -- >> Rowan Collins >> [IMSoP] > > > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. > > Just to clarify - the existence of this RFC effectively means the original
never existed.
> Best regards > > George P. Banyard >
-- Chase Peeler chasepeeler@gmail.com

Girgias

7 years ago
On Tue, 6 Aug 2019 at 19:25, Chase Peeler <chasepeeler@gmail.com> wrote:
> > > On Tue, Aug 6, 2019 at 1:19 PM G. P. B. <george.banyard@gmail.com> wrote: > >> >> >> >> On Tue, 6 Aug 2019 at 19:12, Rowan Collins <rowan.collins@gmail.com> >> wrote: >> >>> On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: >>> >>> > I'm not a voter, but, I have a question. If this fails, does that mean >>> the >>> > original RFC that passed is still in effect? >>> > >>> >>> >>> Yes, this is really ambiguous, and risks the situation being even more >>> confusing than it was before. >>> >>> The "No" column on this RFC already includes people who voted "Yes" on >>> the >>> previous version; is this an indication that they have changed their mind >>> about removing short tags, or that they prefer the original proposal? >>> >>> I think we urgently need to clarify this, and may need to reset the vote >>> with one or more clearer questions. >>> >>> Regards, >>> -- >>> Rowan Collins >>> [IMSoP] >> >> >> This RFC supersedes the previous one as stated in the the RFC itself : " >> This RFC supersedes the previous one and proposes a different >> deprecation approach." meaning that the previous one is void. >> I don't know why this is ambiguous and needs to be said once again. >> >> Just to clarify - the existence of this RFC effectively means the > original never existed. > > >> Best regards >> >> George P. Banyard >> > > > -- > Chase Peeler > chasepeeler@gmail.com >
In a sense yes, however this RFC is a vote on the implementation which would have landed with the previous one but was not the one voted. So you can disregard the result of the previous one not the controversial discussion it generated after the vote was accepted. Hope this clarifies everything. Best regards George P. Banyard

Andrey Andreev

7 years ago
Hi, On Tue, Aug 6, 2019 at 8:20 PM G. P. B. <george.banyard@gmail.com> wrote:
> > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. >
As far as I know, there's been no vote to cancel the previously accepted RFC, so ... even though I didn't like the outcome of it, I don't understand how it is just made void now. It's pretty easy to understand the ambiguity. I won't be voting on this one due to all of this. Cheers, Andrey.

Peter Kokot

7 years ago
Hello, On Wed, 7 Aug 2019 at 09:28, Andrey Andreev <narf@devilix.net> wrote:
> > Hi, > > On Tue, Aug 6, 2019 at 8:20 PM G. P. B. <george.banyard@gmail.com> wrote: > > > > This RFC supersedes the previous one as stated in the the RFC itself : " > > This RFC supersedes the previous one and proposes a different deprecation > > approach." meaning that the previous one is void. > > I don't know why this is ambiguous and needs to be said once again. > > > > As far as I know, there's been no vote to cancel the previously > accepted RFC, so ... even though I didn't like the outcome of it, I > don't understand how it is just made void now. It's pretty easy to > understand the ambiguity. > > I won't be voting on this one due to all of this. > > Cheers, > Andrey. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Yes, last time I was asking this, there was a clarification that certain people from the group internals can veto particular RFC. So, I think that this is the case here.
-- Peter Kokot

Christoph Becker

7 years ago
On 07.08.2019 at 10:44, Peter Kokot wrote:
> On Wed, 7 Aug 2019 at 09:28, Andrey Andreev <narf@devilix.net> wrote: > >> On Tue, Aug 6, 2019 at 8:20 PM G. P. B. <george.banyard@gmail.com> wrote: >> >>> This RFC supersedes the previous one as stated in the the RFC itself : " >>> This RFC supersedes the previous one and proposes a different deprecation >>> approach." meaning that the previous one is void. >>> I don't know why this is ambiguous and needs to be said once again. >> >> As far as I know, there's been no vote to cancel the previously >> accepted RFC, so ... even though I didn't like the outcome of it, I >> don't understand how it is just made void now. It's pretty easy to >> understand the ambiguity. >> >> I won't be voting on this one due to all of this. > > Yes, last time I was asking this, there was a clarification that > certain people from the group internals can veto particular RFC. So, I > think that this is the case here.
I'm not aware of *any* veto rights regarding RFCs. As I understand it, this RFC has been put to vote again, because the first version had some problematic details, and by courtesy to cater to the clamor raised after the voting had finished. Thanks, Christoph

Zeev Suraski

7 years ago
On 7 Aug 2019, at 12:39, Christoph M. Becker <cmbecker69@gmx.de<mailto:cmbecker69@gmx.de>> wrote: As I understand it, this RFC has been put to vote again, because the first version had some problematic details, and by courtesy to cater to the clamor raised after the voting had finished. That is correct. There was an inconsistency with the Voting RFC in the voting options, and the RFC (as it passed) also had catastrophic implications for upgrades - so it could not be implemented as it was written. Zeev

Dan Ackroyd

7 years ago
On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote:
> > Yes, last time I was asking this, there was a clarification that > certain people from the group internals can veto particular RFC.
Please could you point to where this alleged rule has ever been written down or agreed to? Although certain people may have claimed this is a rule, it's never been agreed afaik. I think when we adopt a Code of Conduct one of the things we need to make explicit is that "claiming authority that is not codified" is explicitly a thing that will not be allowed in internals discussions as it seems to keep happening and results in a lot of confusion, and frustration. cheers Dan Ack

Peter Bowyer

7 years ago
On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd <Danack@basereality.com> wrote:
> I think when we adopt a Code of Conduct one of the things we need to > make explicit is that "claiming authority that is not codified" is > explicitly a thing that will not be allowed in internals discussions > as it seems to keep happening and results in a lot of confusion, and > frustration. >
Documenting the project structure would also be helpful. When the PHP Group was mentioned I went hunting for details. I found a list of names at the top of https://www.php.net/credits.php but nothing covering what their role or authority is. Peter

Ben Ramsey

7 years ago
> On Aug 7, 2019, at 09:03, Peter Bowyer <phpmailinglists@gmail.com> wrote: > > On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd <Danack@basereality.com> wrote: > >> I think when we adopt a Code of Conduct one of the things we need to >> make explicit is that "claiming authority that is not codified" is >> explicitly a thing that will not be allowed in internals discussions >> as it seems to keep happening and results in a lot of confusion, and >> frustration. >> > > Documenting the project structure would also be helpful. > > When the PHP Group was mentioned I went hunting for details. I found a list > of names at the top of https://www.php.net/credits.php but nothing covering > what their role or authority is.
Their “role and authority” is copyright ownership of the “code, text, PHP logo, and graphical elements” of the PHP website. https://www.php.net/copyright.php Cheers, Ben

Ben Ramsey

7 years ago
> On Aug 7, 2019, at 09:09, Ben Ramsey <ben@benramsey.com> wrote: > >> On Aug 7, 2019, at 09:03, Peter Bowyer <phpmailinglists@gmail.com> wrote: >> >> On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd <Danack@basereality.com> wrote: >> >>> I think when we adopt a Code of Conduct one of the things we need to >>> make explicit is that "claiming authority that is not codified" is >>> explicitly a thing that will not be allowed in internals discussions >>> as it seems to keep happening and results in a lot of confusion, and >>> frustration. >>> >> >> Documenting the project structure would also be helpful. >> >> When the PHP Group was mentioned I went hunting for details. I found a list >> of names at the top of https://www.php.net/credits.php but nothing covering >> what their role or authority is. > > > Their “role and authority” is copyright ownership of the “code, text, PHP logo, and graphical elements” of the PHP website. https://www.php.net/copyright.php
Clarification: I didn’t mean to imply just the PHP website. I meant the entire part of the PHP code base that is covered by the PHP license. https://github.com/php/php-src/blob/master/LICENSE Cheers, Ben

Zeev Suraski

7 years ago
On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> wrote:
> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: > > > > Yes, last time I was asking this, there was a clarification that > > certain people from the group internals can veto particular RFC. > > Please could you point to where this alleged rule has ever been > written down or agreed to? >
There's indeed no such rule that any individuals have a veto power.
> Although certain people may have claimed this is a rule, it's never > been agreed afaik. >
I'm not aware of anybody who ever claimed that such a rule existed, either. If people are alluding to me - then I don't claim I can veto anything; I think it's also clear from what I think about the short tags deprecation RFC that *if* I had veto power, that would be an instance where I'd use it. The reason we went for V2 aren't because of a veto, but because of issues in the previous RFC. With that said - the source code of PHP is copyrighted by the PHP Group - and it's a fact that is mentioned at the top of every PHP source file. The PHP Group is mostly inactive, and will likely stay this way, but under some extreme situations - it might choose to act (if ever - probably primarily around things that have to do with process). I think when we adopt a Code of Conduct one of the things we need to
> make explicit is that "claiming authority that is not codified" is > explicitly a thing that will not be allowed in internals discussions > as it seems to keep happening and results in a lot of confusion, and > frustration. >
The more accurate word here is 'if', rather than 'when'. But I don't think there's a need to wait for a CoC on this one - it should be clear that no individual has veto powers, but it should be also clear that not everything is up for a vote. Zeev

Peter Kokot

7 years ago
On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote:
> > > > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> wrote: >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: >> > >> > Yes, last time I was asking this, there was a clarification that >> > certain people from the group internals can veto particular RFC. >> >> Please could you point to where this alleged rule has ever been >> written down or agreed to? > > > There's indeed no such rule that any individuals have a veto power. > >> >> Although certain people may have claimed this is a rule, it's never >> been agreed afaik. > > > I'm not aware of anybody who ever claimed that such a rule existed, either. If people are alluding to me - then I don't claim I can veto anything; I think it's also clear from what I think about the short tags deprecation RFC that if I had veto power, that would be an instance where I'd use it. The reason we went for V2 aren't because of a veto, but because of issues in the previous RFC. > > With that said - the source code of PHP is copyrighted by the PHP Group - and it's a fact that is mentioned at the top of every PHP source file. The PHP Group is mostly inactive, and will likely stay this way, but under some extreme situations - it might choose to act (if ever - probably primarily around things that have to do with process). > >> I think when we adopt a Code of Conduct one of the things we need to >> make explicit is that "claiming authority that is not codified" is >> explicitly a thing that will not be allowed in internals discussions >> as it seems to keep happening and results in a lot of confusion, and >> frustration. > > > The more accurate word here is 'if', rather than 'when'. But I don't think there's a need to wait for a CoC on this one - it should be clear that no individual has veto powers, but it should be also clear that not everything is up for a vote. > > Zeev >
Veto has been mentioned here https://externals.io/message/105201#105558 I'm not having any issues with veto being used here or not on a previous RFC from people that are in the internals since day 1. I think we should respect that they have issues with proposals coming up in recent years, but hopefully group will also understand us - users and new contributors a bit that we just want to have a bit of cleanup of legacy things here and there :) Thanks and have a nice day.
-- Peter Kokot

Chase Peeler

7 years ago
On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterkokot@gmail.com> wrote:
> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote: > > > > > > > > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> > wrote: > >> > >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: > >> > > >> > Yes, last time I was asking this, there was a clarification that > >> > certain people from the group internals can veto particular RFC. > >> > >> Please could you point to where this alleged rule has ever been > >> written down or agreed to? > > > > > > There's indeed no such rule that any individuals have a veto power. > > > >> > >> Although certain people may have claimed this is a rule, it's never > >> been agreed afaik. > > > > > > I'm not aware of anybody who ever claimed that such a rule existed, > either. If people are alluding to me - then I don't claim I can veto > anything; I think it's also clear from what I think about the short tags > deprecation RFC that if I had veto power, that would be an instance where > I'd use it. The reason we went for V2 aren't because of a veto, but > because of issues in the previous RFC. > > > > With that said - the source code of PHP is copyrighted by the PHP Group > - and it's a fact that is mentioned at the top of every PHP source file. > The PHP Group is mostly inactive, and will likely stay this way, but under > some extreme situations - it might choose to act (if ever - probably > primarily around things that have to do with process). > > > >> I think when we adopt a Code of Conduct one of the things we need to > >> make explicit is that "claiming authority that is not codified" is > >> explicitly a thing that will not be allowed in internals discussions > >> as it seems to keep happening and results in a lot of confusion, and > >> frustration. > > > > > > The more accurate word here is 'if', rather than 'when'. But I don't > think there's a need to wait for a CoC on this one - it should be clear > that no individual has veto powers, but it should be also clear that not > everything is up for a vote. > > > > Zeev > > > > Veto has been mentioned here > https://externals.io/message/105201#105558 > > I'm not having any issues with veto being used here or not on a > previous RFC from people that are in the internals since day 1. I > think we should respect that they have issues with proposals coming up > in recent years, but hopefully group will also understand us - users > and new contributors a bit that we just want to have a bit of cleanup > of legacy things here and there :) > > Thanks and have a nice day. > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > What powers are available, and to whom they are available, is probably
something that should be moved to another thread. We currently have at least three different discussions going on in this thread: 1.) The RFC itself 2.) Default handling of the ini setting 3.) Whether certain people can veto RFCs. To address Andrey's initial concern, which is currently leading to him not voting: Nobody is vetoing anything. Due to both the procedural issues (the way the voting was structured with two options) as well as the severity of the issues raised after the voting, another RFC was proposed that supersedes the original RFC. The procedural issues alone were enough to warrant another vote on an RFC that had fixed those issues. This means that, for all intents and purposes, the first RFC never existed. If the current RFC passes, then it will be implemented as proposed. If it fails, then treatment of short tags will remain as it currently is. I hope you will reconsider your decision to not vote on this new RFC. I understand your concerns. As someone that didn't like the outcome of the first vote either, I also didn't feel that a revote just because a lot of people decided to speak up after the fact was the correct course of action. I don't think that is what is happening here, though.
-- Chase Peeler chasepeeler@gmail.com

Nikita Popov

7 years ago
On Tue, Aug 6, 2019 at 1:34 PM G. P. B. <george.banyard@gmail.com> wrote:
> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >
Side-note: Even if this RFC fails, we should probably still make it an error to use <? without short_tags being **explicitly** enabled, so that we may flip the default to off at some later point in time. The current default being "on" despite their use being discouraged is half the trouble. Nikita

Zeev Suraski

7 years ago
> On 6 Aug 2019, at 21:46, Nikita Popov <nikita.ppv@gmail.com> wrote: > >> On Tue, Aug 6, 2019 at 1:34 PM G. P. B. <george.banyard@gmail.com> wrote: >> >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> It is expected to last two (2) weeks until 2019-08-20. >> >> A counter argument to this RFC is available at >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> >> Best regards >> >> George P. Banyard >> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> > > Side-note: Even if this RFC fails, we should probably still make it an > error to use <? without short_tags being **explicitly** enabled, so that we > may flip the default to off at some later point in time. The current > default being "on" despite their use being discouraged is half the trouble. >
That’s a good idea. I was genuinely surprised to learn that wasn’t already the case, although the actual impact of that is quite limited given the fact that virtually all common deployments come preconfigured with short tags set to off. Zeev

Claude Pache

7 years ago
> Le 6 août 2019 à 20:46, Nikita Popov <nikita.ppv@gmail.com> a écrit : > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. <george.banyard@gmail.com> wrote: > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> It is expected to last two (2) weeks until 2019-08-20. >> >> A counter argument to this RFC is available at >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> >> Best regards >> >> George P. Banyard >> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> > > Side-note: Even if this RFC fails, we should probably still make it an > error to use <? without short_tags being **explicitly** enabled, so that we > may flip the default to off at some later point in time. The current > default being "on" despite their use being discouraged is half the trouble. > > Nikita
That would mean in particular that XML documents could no longer be preprocessed by PHP without boilerplate around its `<?xml ?>` declaration. I doubt that this is a more acceptable breaking change than deprecating short_tags. —Claude

Walter Parker

7 years ago
On Tue, Aug 6, 2019 at 2:55 PM Claude Pache <claude.pache@gmail.com> wrote:
> > > > Le 6 août 2019 à 20:46, Nikita Popov <nikita.ppv@gmail.com> a écrit : > > > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. <george.banyard@gmail.com> > wrote: > > > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > >> It is expected to last two (2) weeks until 2019-08-20. > >> > >> A counter argument to this RFC is available at > >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > >> > >> Best regards > >> > >> George P. Banyard > >> > >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > >> > > > > Side-note: Even if this RFC fails, we should probably still make it an > > error to use <? without short_tags being **explicitly** enabled, so that > we > > may flip the default to off at some later point in time. The current > > default being "on" despite their use being discouraged is half the > trouble. > > > > Nikita > > > That would mean in particular that XML documents could no longer be > preprocessed by PHP without boilerplate around its `<?xml ?>` declaration. > I doubt that this is a more acceptable breaking change than deprecating > short_tags. > > —Claude > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Why would you want to use PHP's preprocessor for XML?
Why not use the right tool for the job? Such as an XML processor that could also do schema validation? PHP has XML processing packages. It has been a while since I did XML processing, but I don't remember the packages being all that difficult to use. Is this a mixing data and code into the same file problem? Like HTML files that have PHP embedded directly in the file? Or this about stuffing PHP inside of XML documents? Walter
-- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis

Nikita Popov

7 years ago
On Tue, Aug 6, 2019 at 11:55 PM Claude Pache <claude.pache@gmail.com> wrote:
> > > > Le 6 août 2019 à 20:46, Nikita Popov <nikita.ppv@gmail.com> a écrit : > > > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. <george.banyard@gmail.com> > wrote: > > > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > >> It is expected to last two (2) weeks until 2019-08-20. > >> > >> A counter argument to this RFC is available at > >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > >> > >> Best regards > >> > >> George P. Banyard > >> > >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > >> > > > > Side-note: Even if this RFC fails, we should probably still make it an > > error to use <? without short_tags being **explicitly** enabled, so that > we > > may flip the default to off at some later point in time. The current > > default being "on" despite their use being discouraged is half the > trouble. > > > > Nikita > > > That would mean in particular that XML documents could no longer be > preprocessed by PHP without boilerplate around its `<?xml ?>` declaration. > I doubt that this is a more acceptable breaking change than deprecating > short_tags.
To clarify: What I had in mind is that use of <? results in an error if and only if short_tags is left at its default value (of On). If short_tags is explicitly Off or explicitly On, everything works as usual. Embedding <?xml ?> in PHP code requires an explicit short_tags=Off right now, so the situation there shouldn't change, unless I'm missing something. The only motivation here is to allow us to change the default to short_tags=Off at some point in the future (say PHP 9), after enough time has passed where short_tags cannot be used by default, without explicitly being enabled. We can't just flip the default right now due to the usual code leaking concerns. Regards, Nikita

Rowan Collins

7 years ago
On 07/08/2019 09:11, Nikita Popov wrote:
> To clarify: What I had in mind is that use of <? results in an error if and > only if short_tags is left at its default value (of On). If short_tags is > explicitly Off or explicitly On, everything works as usual. Embedding <?xml > ?> in PHP code requires an explicit short_tags=Off right now, so the > situation there shouldn't change, unless I'm missing something.
Since it would behave differently, it wouldn't make sense to say that it defaulted to "On", but that actually leads to an interesting feature: add an "error" mode to that setting. So the options would be: - error: any use of "<?" other than "<?php" and "<?=" would raise an error; compile-time default - off: "<?" is ignored and passed through to output; ini default shipped by most packages - on: "<?" is equivalent to "<?php"; no longer any kind of default We could either leave the recommended ini setting in the official distribution as "off" (more compatible) or set it to "error" (to make mistakes safer and easier to spot). Regards.
-- Rowan Collins [IMSoP]

Nicolas Grekas

7 years ago
Le mar. 6 août 2019 à 13:34, G. P. B. <george.banyard@gmail.com> a écrit :
> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
The counter-arguments are a really nice addition to the process. Reading them made me think there is a big missing "pro" argument: perceived complexity of the engine. When there is no choice to make (short tags on/off, magic_quote on/off, etc), then there is only one thing to teach, one thing to learn, one thing to (not have to) agree on when deciding for some conventions, etc. When there are N binary options (and not all options are binary), there are 2^N things to teach, learn, etc. That's a major cost put on the community. Choices that were made years ago when PHP was not what it is today were certainly fine, but nowadays, this imposes significant a burden on everyone. Each option individually are maybe minor, but the 2^N becomes quickly big. I think we should make such things way simpler so that we can free the brains of many to do the next things that matter. I don't have a vote, but if I were I would vote "yes". Instead, I encourage "no"-voters to reconsider, and others to vote "yes" too :) Cheers, Nicolas

Chase Peeler

7 years ago
On Wed, Aug 7, 2019 at 1:14 PM Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote:
> Le mar. 6 août 2019 à 13:34, G. P. B. <george.banyard@gmail.com> a écrit : > > > The voting for the "Deprecate short open tags, again" [1] RFC has begun. > > It is expected to last two (2) weeks until 2019-08-20. > > > > A counter argument to this RFC is available at > > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > > > Best regards > > > > George P. Banyard > > > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > > > > The counter-arguments are a really nice addition to the process. > > Reading them made me think there is a big missing "pro" argument: perceived > complexity of the engine. > > When there is no choice to make (short tags on/off, magic_quote on/off, > etc), then there is only one thing to teach, one thing to learn, one thing > to (not have to) agree on when deciding for some conventions, etc. > > When there are N binary options (and not all options are binary), there are > 2^N things to teach, learn, etc. > > In this case, claiming a slippery-slope is a logical fallacy. We aren't
talking about opening it up so that we can add even more opening tags in the future. The odds are pretty much zero that keeping short tags would lead to it in the future. We're talking about two possible ways to begin a block of PHP code. <? and <?php. Pretty much everyone (if not actually everyone) that is against this RFC has stated that they don't actually use short tags, and do not advocate that anyone else use them either.
> That's a major cost put on the community. Choices that were made years ago > when PHP was not what it is today were certainly fine, but nowadays, this > imposes significant a burden on everyone. Each option individually are > maybe minor, but the 2^N becomes quickly big. I think we should make such > things way simpler so that we can free the brains of many to do the next > things that matter. > > I think the cost put on the community to fix existing instances of short
tags is a MUCH higher burden than asking them know about the existence of short tags should they encounter them one day. I'm in charge of maintaining a very large legacy code base. The majority of the legacy code is "leave it alone code" that is slowly getting re-written. The code is horrendous. Things have broken in the past from running PhpStorm's auto-formatting on a file. The effort required to update all of that code in order to upgrade would be so high that it's likely I would never get approval from my superiors to spend that much time on it.
> I don't have a vote, but if I were I would vote "yes". Instead, I encourage > "no"-voters to reconsider, and others to vote "yes" too :) > > Cheers, > Nicolas >
-- Chase Peeler chasepeeler@gmail.com

Côme Chilliet

7 years ago
Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :
> Pretty much everyone (if not actually > everyone) that is against this RFC has stated that they don't actually use > short tags, and do not advocate that anyone else use them either.
This is what bugs me, the counter argument page from Zeev states «I never use short tags in any PHP code that I write, and as far as I recall - I never have. », and at the same time «put hundreds of thousands of people through additional pain when upgrading.» Is there any data that support the theory that hundreds of thousands of people use short tags? Did anyone in this discussion stated that he was using them?

Reinis Rozitis

7 years ago
> -----Original Message----- > From: Côme Chilliet [mailto:come@opensides.be] > > This is what bugs me, the counter argument page from Zeev states «I never > use short tags in any PHP code that I write, and as far as I recall - I never > have. », and at the same time «put hundreds of thousands of people > through additional pain when upgrading.»
Why does/should it bug you? The statements aren't contradictory. There are (must be) a lot of features which a particular language developer might not use (or even find ridiculous) himself personally but those still have been implemented historically or for future use for other users/clients etc.
> Did anyone in this discussion stated that he was using them?
Yes. rr

Brent

7 years ago
I asked similar questions on Twitter, where Zeev replied the following: https://mobile.twitter.com/zeevs/status/1158688885658046464 It feels like much of the counter arguments are based on guesses without any real data to point to. On the other hand it's unfair to dismiss the counter arguments altogether because of this, as there's no way to gather accurate data about the usage of short open tags, let alone know how many developers using them actually plan on ever upgrading to 7.4… Kind regards Brent On 8 Aug 2019, 12:27 +0200, Côme Chilliet <come@opensides.be>, wrote:

Reinis Rozitis

7 years ago
> -----Original Message----- > From: Brent [mailto:brendt@stitcher.io] > > > It feels like much of the counter arguments are based on guesses without any > real data to point to.
It goes both ways - the argument for removal states "This means that their use is not possible in portable code, because the code author does not necessarily have the necessary control over the configuration". What is the number/statistics of developers which have written a portable (in their mind) code (which means NOT using short tags) just to find out that the code/application doesn't work because those are disabled? Is there real data for that? rr

Rowan Collins

7 years ago
On 8 August 2019 13:16:56 BST, Brent <brendt@stitcher.io> wrote:
>I asked similar questions on Twitter, where Zeev replied the >following: > >> With an estimated number of PHP developers >> at 10M, 1% is 100K. Whether I know this for >> sure is not at all the point - it's never how we >> take decisions. The question is whether it's >> reasonable or not. And my guess is that a lot >> more than 1% uses short tags. > >It feels like much of the counter arguments are based on guesses >without any real data to point to.
You can take that both ways though: the argument that short tags should be removed is based on the same guesses. I understand Zeev's frustration in being asked to provide the proof when his position is that we shouldn't be spending any time on the issue at all. It should be up to those who think a change is necessary to demonstrate both the harm of the status quo (e.g. real-world cases of code exposure), and that it outweighs the cost of change (e.g. how many users will need to change working code). It would be different if we were choosing between two versions of some feature, but no-change should always have a starting advantage over change, which is why we require a super-majority in primary RFC votes. Regards,
-- Rowan Collins [IMSoP]

Zeev Suraski

7 years ago
On Thu, Aug 8, 2019 at 3:17 PM Brent <brendt@stitcher.io> wrote:
> I asked similar questions on Twitter, where Zeev replied the following: > https://mobile.twitter.com/zeevs/status/1158688885658046464
I want to add a bit of color to this tweet: - Estimated # of developers using PHP is at around 10M. This is based on some extrapolation from an EDS report from ~8 years ago that estimated that number at >6M, and growth rates we've seen beforehand. - Anecdotally, I've seen it used many times in non-distributable code over the years - a lot more frequently than once per 100 users. - Even if just 1% of the userbase uses short tags, that's ~100K. We can call this one a guess, but I'd say it's an educated guess that there's well above 1% of the PHP userbase that uses short tags. It feels like much of the counter arguments are based on guesses without
> any real data to point to.
I wouldn't say they're guesses, but extrapolations - for instance, the fact I'm aware of many PHP frameworks and apps, and am not aware of any single one that allows short tags - makes me feel fairly comfortable to make the statement that "virtually all frameworks and apps designed for public consumption disallow short tags". I can't preclude the possibility that the fact that all of the apps and frameworks I'm aware of don't allow short tags is a remarkable coincidence - or that there are countless ones I'm not aware of that do allow short tags - but I think that my theory is a lot more plausible. Zeev

Chase Peeler

7 years ago
On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski <zeev@php.net> wrote:
> On Thu, Aug 8, 2019 at 3:17 PM Brent <brendt@stitcher.io> wrote: > > > I asked similar questions on Twitter, where Zeev replied the following: > > https://mobile.twitter.com/zeevs/status/1158688885658046464 > > > I want to add a bit of color to this tweet: > - Estimated # of developers using PHP is at around 10M. This is based on > some extrapolation from an EDS report from ~8 years ago that estimated that > number at >6M, and growth rates we've seen beforehand. > - Anecdotally, I've seen it used many times in non-distributable code over > the years - a lot more frequently than once per 100 users. > - Even if just 1% of the userbase uses short tags, that's ~100K. We can > call this one a guess, but I'd say it's an educated guess that there's well > above 1% of the PHP userbase that uses short tags. > > It feels like much of the counter arguments are based on guesses without > > any real data to point to. > > > I wouldn't say they're guesses, but extrapolations - for instance, the fact > I'm aware of many PHP frameworks and apps, and am not aware of any single > one that allows short tags - makes me feel fairly comfortable to make the > statement that "virtually all frameworks and apps designed for public > consumption disallow short tags". I can't preclude the possibility that > the fact that all of the apps and frameworks I'm aware of don't allow short > tags is a remarkable coincidence - or that there are countless ones I'm not > aware of that do allow short tags - but I think that my theory is a lot > more plausible. > > I work on an internal application. Even though portability is not a
concern for anything we write, we haven't used short tags since it was rumored they were going to be removed in PHP 6 many years ago. That being said, this application has been in development since 2003. There is a large amount of legacy code written before I even started here, not to mention plenty of horrible code written after I did start in 2005 (this was my first job). As I mentioned in an email on this thread yesterday, most of our legacy code is "just leave it alone, it works" code. We are in the process of rewriting things, but, that takes time. We try and mess with the legacy code as little as possible. Something as simple as auto formatting with PhpStorm has broken things in the past - so I don't trust an automated tool to fix the short tags for me. Even if I'm the only person that has participated in this thread that has to maintain a codebase that consists of non-portable code with a large amount of short tags, that's still at least 1% of those that have participated in this thread, or one of its predecessors. Another thing to keep in mind is that most of the people writing and/or maintaining "non-portable" code probably don't work for a company in the software development industry. When I want to upgrade PHP, I have to convince our leadership of the value of me spending a couple of weeks fixing BC breaks. I have to show why that is more valuable than spending time on the development of new functionality. The more time required to do an upgrade, the more likely it will get punted to a future date. I'm not against BC breaks in general - they are a necessary evil. However, it's important that the negative impact of that break is far outweighed by the positive value it brings. I'll leave it up to each of you to determine how positive of an impact removing short tags would bring. I can promise you, though, that the negative impact would be VERY large. Just because you don't personally have to maintain any code that uses short tags doesn't mean that there aren't other developers out there that do. Every BC break is going to lead to a subset of users that will decide to not upgrade as a result. It will also lead to a subset of users that will decide to use a different technology (node, .NET, python, etc.) going forward. Many BC breaks are worth that risk. Is this one of them? Many people have talked about the potential impacts of keeping short tags. I have yet to see anyone give an actual example where they have been negatively impacted by their existence. I've given you my personal story of how removing them will negatively impact my company. I welcome anyone that can provide an actual incident where the existence of short tags hurt them, or, the continued existence is likely to have a large negative impact on them in the future.
> Zeev >
-- Chase Peeler chasepeeler@gmail.com

Peter Kokot

7 years ago
Hello, On Thu, 8 Aug 2019 at 16:17, Chase Peeler <chasepeeler@gmail.com> wrote:
> > On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski <zeev@php.net> wrote: > > > On Thu, Aug 8, 2019 at 3:17 PM Brent <brendt@stitcher.io> wrote: > > > > > I asked similar questions on Twitter, where Zeev replied the following: > > > https://mobile.twitter.com/zeevs/status/1158688885658046464 > > > > > > I want to add a bit of color to this tweet: > > - Estimated # of developers using PHP is at around 10M. This is based on > > some extrapolation from an EDS report from ~8 years ago that estimated that > > number at >6M, and growth rates we've seen beforehand. > > - Anecdotally, I've seen it used many times in non-distributable code over > > the years - a lot more frequently than once per 100 users. > > - Even if just 1% of the userbase uses short tags, that's ~100K. We can > > call this one a guess, but I'd say it's an educated guess that there's well > > above 1% of the PHP userbase that uses short tags. > > > > It feels like much of the counter arguments are based on guesses without > > > any real data to point to. > > > > > > I wouldn't say they're guesses, but extrapolations - for instance, the fact > > I'm aware of many PHP frameworks and apps, and am not aware of any single > > one that allows short tags - makes me feel fairly comfortable to make the > > statement that "virtually all frameworks and apps designed for public > > consumption disallow short tags". I can't preclude the possibility that > > the fact that all of the apps and frameworks I'm aware of don't allow short > > tags is a remarkable coincidence - or that there are countless ones I'm not > > aware of that do allow short tags - but I think that my theory is a lot > > more plausible. > > > > I work on an internal application. Even though portability is not a > concern for anything we write, we haven't used short tags since it was > rumored they were going to be removed in PHP 6 many years ago. That being > said, this application has been in development since 2003. There is a large > amount of legacy code written before I even started here, not to mention > plenty of horrible code written after I did start in 2005 (this was my > first job). As I mentioned in an email on this thread yesterday, most of > our legacy code is "just leave it alone, it works" code. We are in the > process of rewriting things, but, that takes time. We try and mess with the > legacy code as little as possible. Something as simple as auto formatting > with PhpStorm has broken things in the past - so I don't trust an automated > tool to fix the short tags for me. Even if I'm the only person that has > participated in this thread that has to maintain a codebase that consists > of non-portable code with a large amount of short tags, that's still at > least 1% of those that have participated in this thread, or one of its > predecessors. > > Another thing to keep in mind is that most of the people writing and/or > maintaining "non-portable" code probably don't work for a company in the > software development industry. When I want to upgrade PHP, I have to > convince our leadership of the value of me spending a couple of weeks > fixing BC breaks. I have to show why that is more valuable than spending > time on the development of new functionality. The more time required to do > an upgrade, the more likely it will get punted to a future date. > > I'm not against BC breaks in general - they are a necessary evil. However, > it's important that the negative impact of that break is far outweighed by > the positive value it brings. I'll leave it up to each of you to determine > how positive of an impact removing short tags would bring. I can promise > you, though, that the negative impact would be VERY large. Just because you > don't personally have to maintain any code that uses short tags doesn't > mean that there aren't other developers out there that do. Every BC break > is going to lead to a subset of users that will decide to not upgrade as a > result. It will also lead to a subset of users that will decide to use a > different technology (node, .NET, python, etc.) going forward. Many BC > breaks are worth that risk. Is this one of them? > > Many people have talked about the potential impacts of keeping short tags. > I have yet to see anyone give an actual example where they have been > negatively impacted by their existence. I've given you my personal story of > how removing them will negatively impact my company. I welcome anyone that > can provide an actual incident where the existence of short tags hurt them, > or, the continued existence is likely to have a large negative impact on > them in the future. > > > > Zeev > > > > > -- > Chase Peeler > chasepeeler@gmail.com
Thanks for sharing your stories about issues. Maybe we should start also thinking about the impact on the language attractiveness to pick it when starting a new web project since the core people can't come to conclusions how to make the language more consistent on the long run (PHP 9 etc)... With more and more ambiguities, inconsistencies, lockups, and dead ends behind the language there is probably also a bit of a factor to consider that it lowers this attractiveness. Meaning less people will think of adopting it (with all the things combined - short tags, that and that inconsistency not being removed from PHP due to major disastrous BC break there and there). So, the damage is also on the long run with more and more locks and dead ends not being able to be fixed and cleaned.
-- Peter Kokot

Arvids Godjuks

7 years ago
чт, 8 авг. 2019 г. в 16:42, Peter Kokot <peterkokot@gmail.com>:
> Hello, > Thanks for sharing your stories about issues. Maybe we should start > also thinking about the impact on the language attractiveness to pick > it when starting a new web project since the core people can't come to > conclusions how to make the language more consistent on the long run > (PHP 9 etc)... With more and more ambiguities, inconsistencies, > lockups, and dead ends behind the language there is probably also a > bit of a factor to consider that it lowers this attractiveness. > Meaning less people will think of adopting it (with all the things > combined - short tags, that and that inconsistency not being removed > from PHP due to major disastrous BC break there and there). So, the > damage is also on the long run with more and more locks and dead ends > not being able to be fixed and cleaned. > > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Hello. Peter above put my thoughts perfectly. BC is great, but you need to pull the cord at some point. And the whole short tag back and forth, with deprecation warning and stuff, has been around for last half a decade. It is time to accept that it needs to go and there should be no runtime dependent switch for this. Valid PHP tags are `<?php` and `<?=` and that's it. I really liked how language picked up the cleanup pace in the last few years and it needs it. I finally see genuine interest in people to actually either come back or pick it up instead of JavaScript (NodeJS) and other fancy new shiny stuff. And a lot of it is because of the cleanup efforts and WTF?! removal, the language having the option to be stricter (I was not a fan of strict mode when it was coming up - now I don't use anything else - it is AWESOME). If the old guard starts to push back as much as I have seen here, we are going to lose momentum as a community and have people not willing to work on PHP as much. I mean anyone who has been on this list for more than 10 years should remember how it was in 5.0-5.4 days - slow, painful and somewhat unfriendly, until a few major contributors kind'a muddled though and pushed a few major changes that allowed the momentum to build up and somewhat break the stalemate (and it did help that HHVM reared it's head and had stroked a few egos the wrong way). I guess the curve repeats itself, but we should make an effort to curb it and not revert back to "BC, BC, BC!!!!" holding everything up. Reality is, a lot of those "non-tech company" examples people give here has nothing to do with language evolution. Yes, they are users, but we are not responsible for the code they write, for the way they configure their web servers and the way they can run a PHP4 server past 10 years and still have no clue, because nobody cares or "it works, it makes money, no need to invest". I would say that most of us on this list, if not everyone, are smart enough to run/leave/not work for companies like that, so we are somewhat shielded from that ignorance and just forget how bad it can be. Long story short - indecision is not an option. The previous RFC has passed. Everyone involved, I hope, understands that yes, there will be stuff going wrong for some users who are careless and/or ignorant and live under a rock. Can we really do anything about that? I would say no unless we freeze the language and do nothing. I mean I have exposed my PHP code during server setup by just forgetting to do `systemctl reload nginx`, hitting the URL and getting my `index.php` on the screen more times than I care to confess to. Let's look into the future, use a reasonable amount of caution and/or deprecation notice periods, but please stop trying to block features "because stupid users". You give them the most secure software you can write, they go change settings on their own and get p0wned/defaced/hacked anyway even when you tell them not to do it and that y'r refusing to work on their project because of decisions they make.
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

Rowan Collins

7 years ago
On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
> BC is great, but you need to pull the cord at some point. And the whole > short tag back and forth, with deprecation warning and stuff, has been > around for last half a decade. It is time to accept that it needs to go >
That's like saying from now on we should mandate PSR-2 indenting style in the compiler, to stop people arguing about code formatting. Just because people keep saying something, doesn't make it right.
> If the old guard starts to push back as much as I have seen here, we are > going to lose momentum as a community and have people not willing to work > on PHP as much. >
I feel like the opposite: if people volunteering their time find that all their energy is spent on pointless arguments about removing working features, and none of it is spent on actually innovating the language, they'll spend it somewhere else.
> Long story short - indecision is not an option.
Here's a decision for you then: short tags are fine how they are, and we can stop wasting energy talking about them and get on with doing something that actually benefits the language. That's not indecision, that's a concrete position we could take to prioritise our efforts on something more productive. The previous RFC has
> passed. Everyone involved, I hope, understands that yes, there will be > stuff going wrong for some users who are careless and/or ignorant and live > under a rock. Can we really do anything about that?
Yes. Yes, we can. We can do what's proposed in the v2 RFC, or we can reverse our decision. An RFC passing isn't a pact with the devil.
> Let's look into the future, use a reasonable amount of caution and/or > deprecation notice periods, but please stop trying to block features >
What is the feature being blocked if we leave short tags in PHP? If such a feature existed, I would understand your frustration - but if it did, the RFC could make the case for why adding that new feature was worth the pain caused by removing the old feature. Since there is no such feature, there is no such justification in the RFC, which is why it's so controversial. Regards,
-- Rowan Collins [IMSoP]

Chase Peeler

7 years ago
On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
> чт, 8 авг. 2019 г. в 16:42, Peter Kokot <peterkokot@gmail.com>: > >> Hello, >> Thanks for sharing your stories about issues. Maybe we should start >> also thinking about the impact on the language attractiveness to pick >> it when starting a new web project since the core people can't come to >> conclusions how to make the language more consistent on the long run >> (PHP 9 etc)... With more and more ambiguities, inconsistencies, >> lockups, and dead ends behind the language there is probably also a >> bit of a factor to consider that it lowers this attractiveness. >> Meaning less people will think of adopting it (with all the things >> combined - short tags, that and that inconsistency not being removed >> from PHP due to major disastrous BC break there and there). So, the >> damage is also on the long run with more and more locks and dead ends >> not being able to be fixed and cleaned. >> >> >> -- >> Peter Kokot >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Hello. > > Peter above put my thoughts perfectly. > > BC is great, but you need to pull the cord at some point. And the whole > short tag back and forth, with deprecation warning and stuff, has been > around for last half a decade. It is time to accept that it needs to go and > there should be no runtime dependent switch for this. Valid PHP tags are > `<?php` and `<?=` and that's it. > I really liked how language picked up the cleanup pace in the last few > years and it needs it. I finally see genuine interest in people to actually > either come back or pick it up instead of JavaScript (NodeJS) and other > fancy new shiny stuff. And a lot of it is because of the cleanup efforts > and WTF?! removal, the language having the option to be stricter (I was not > a fan of strict mode when it was coming up - now I don't use anything else > - it is AWESOME). > If the old guard starts to push back as much as I have seen here, we are > going to lose momentum as a community and have people not willing to work > on PHP as much. I mean anyone who has been on this list for more than 10 > years should remember how it was in 5.0-5.4 days - slow, painful and > somewhat unfriendly, until a few major contributors kind'a muddled though > and pushed a few major changes that allowed the momentum to build up and > somewhat break the stalemate (and it did help that HHVM reared it's head > and had stroked a few egos the wrong way). I guess the curve repeats > itself, but we should make an effort to curb it and not revert back to "BC, > BC, BC!!!!" holding everything up. > > Wait, how could positive progress have been made while short tags still
existed?
> Reality is, a lot of those "non-tech company" examples people give here > has nothing to do with language evolution. Yes, they are users, but we are > not responsible for the code they write, for the way they configure their > web servers and the way they can run a PHP4 server past 10 years and still > have no clue, because nobody cares or "it works, it makes money, no need to > invest". I would say that most of us on this list, if not everyone, are > smart enough to run/leave/not work for companies like that, so we are > somewhat shielded from that ignorance and just forget how bad it can be. > > Long story short - indecision is not an option. The previous RFC has > passed. Everyone involved, I hope, understands that yes, there will be > stuff going wrong for some users who are careless and/or ignorant and live > under a rock. Can we really do anything about that? I would say no unless > we freeze the language and do nothing. I mean I have exposed my PHP code > during server setup by just forgetting to do `systemctl reload nginx`, > hitting the URL and getting my `index.php` on the screen more times than I > care to confess to. >
You're in the "all or nothing" logical fallacy. You are acting as if being against the removal of short tags is the same as being against any BC break at all. As we've said MANY times, BC breaks aren't the issue. THIS PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the users and does very little, if anything, to improve the language. At the same time it WILL lead to a very big barrier in terms of the ability to upgrade for a large number of users.
> Let's look into the future, use a reasonable amount of caution and/or > deprecation notice periods, but please stop trying to block features > "because stupid users". You give them the most secure software you can > write, they go change settings on their own and get p0wned/defaced/hacked > anyway even when you tell them not to do it and that y'r refusing to work > on their project because of decisions they make. > > Actually, most BC breaks, including this one, seem to be focused on
preventing issues from "stupid users." We're saying that short tags are bad because of reasons. We can't trust users to not use short tags as long as they exist, so we must force them to stop using them, no matter how painful that might be. That's actually an OK thing to do if the reasons for doing so justify it. I have yet to see the justification. All I've seen is people attempt to mitigate the cost of the break, or, say the cost doesn't really matter.
> -- > Arvīds Godjuks > > +371 26 851 664 > arvids.godjuks@gmail.com > Skype: psihius > Telegram: @psihius https://t.me/psihius >
-- Chase Peeler chasepeeler@gmail.com

Chase Peeler

7 years ago
On Thu, Aug 8, 2019 at 10:42 AM Peter Kokot <peterkokot@gmail.com> wrote:
> Hello, > > On Thu, 8 Aug 2019 at 16:17, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski <zeev@php.net> wrote: > > > > > On Thu, Aug 8, 2019 at 3:17 PM Brent <brendt@stitcher.io> wrote: > > > > > > > I asked similar questions on Twitter, where Zeev replied the > following: > > > > https://mobile.twitter.com/zeevs/status/1158688885658046464 > > > > > > > > > I want to add a bit of color to this tweet: > > > - Estimated # of developers using PHP is at around 10M. This is based > on > > > some extrapolation from an EDS report from ~8 years ago that estimated > that > > > number at >6M, and growth rates we've seen beforehand. > > > - Anecdotally, I've seen it used many times in non-distributable code > over > > > the years - a lot more frequently than once per 100 users. > > > - Even if just 1% of the userbase uses short tags, that's ~100K. We > can > > > call this one a guess, but I'd say it's an educated guess that there's > well > > > above 1% of the PHP userbase that uses short tags. > > > > > > It feels like much of the counter arguments are based on guesses > without > > > > any real data to point to. > > > > > > > > > I wouldn't say they're guesses, but extrapolations - for instance, the > fact > > > I'm aware of many PHP frameworks and apps, and am not aware of any > single > > > one that allows short tags - makes me feel fairly comfortable to make > the > > > statement that "virtually all frameworks and apps designed for public > > > consumption disallow short tags". I can't preclude the possibility > that > > > the fact that all of the apps and frameworks I'm aware of don't allow > short > > > tags is a remarkable coincidence - or that there are countless ones > I'm not > > > aware of that do allow short tags - but I think that my theory is a lot > > > more plausible. > > > > > > I work on an internal application. Even though portability is not a > > concern for anything we write, we haven't used short tags since it was > > rumored they were going to be removed in PHP 6 many years ago. That being > > said, this application has been in development since 2003. There is a > large > > amount of legacy code written before I even started here, not to mention > > plenty of horrible code written after I did start in 2005 (this was my > > first job). As I mentioned in an email on this thread yesterday, most of > > our legacy code is "just leave it alone, it works" code. We are in the > > process of rewriting things, but, that takes time. We try and mess with > the > > legacy code as little as possible. Something as simple as auto formatting > > with PhpStorm has broken things in the past - so I don't trust an > automated > > tool to fix the short tags for me. Even if I'm the only person that has > > participated in this thread that has to maintain a codebase that consists > > of non-portable code with a large amount of short tags, that's still at > > least 1% of those that have participated in this thread, or one of its > > predecessors. > > > > Another thing to keep in mind is that most of the people writing and/or > > maintaining "non-portable" code probably don't work for a company in the > > software development industry. When I want to upgrade PHP, I have to > > convince our leadership of the value of me spending a couple of weeks > > fixing BC breaks. I have to show why that is more valuable than spending > > time on the development of new functionality. The more time required to > do > > an upgrade, the more likely it will get punted to a future date. > > > > I'm not against BC breaks in general - they are a necessary evil. > However, > > it's important that the negative impact of that break is far outweighed > by > > the positive value it brings. I'll leave it up to each of you to > determine > > how positive of an impact removing short tags would bring. I can promise > > you, though, that the negative impact would be VERY large. Just because > you > > don't personally have to maintain any code that uses short tags doesn't > > mean that there aren't other developers out there that do. Every BC break > > is going to lead to a subset of users that will decide to not upgrade as > a > > result. It will also lead to a subset of users that will decide to use a > > different technology (node, .NET, python, etc.) going forward. Many BC > > breaks are worth that risk. Is this one of them? > > > > Many people have talked about the potential impacts of keeping short > tags. > > I have yet to see anyone give an actual example where they have been > > negatively impacted by their existence. I've given you my personal story > of > > how removing them will negatively impact my company. I welcome anyone > that > > can provide an actual incident where the existence of short tags hurt > them, > > or, the continued existence is likely to have a large negative impact on > > them in the future. > > > > > > > Zeev > > > > > > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > Thanks for sharing your stories about issues. Maybe we should start > also thinking about the impact on the language attractiveness to pick > it when starting a new web project since the core people can't come to > conclusions how to make the language more consistent on the long run > (PHP 9 etc)... With more and more ambiguities, inconsistencies, > lockups, and dead ends behind the language there is probably also a > bit of a factor to consider that it lowers this attractiveness. > Meaning less people will think of adopting it (with all the things > combined - short tags, that and that inconsistency not being removed
from PHP due to major disastrous BC break there and there). So, the damage is also on the long run with more and more locks and dead ends
> not being able to be fixed and cleaned. > > Can you find me one person that has chosen to not use PHP because it
supports two types of opening tags? I'll make you a deal. If we can get rid of every other "inconsistency, ambiguity, lockup, and dead end" in the language, then I will come out in full support of removing short tags. Let's also get rid of every camelCase function and change it to underscore_case. That will help consistency. I'm personally willing to bet that more people are turned off by PHP's inconsistent function naming than the fact it allows multiple opening tags. I'll amend my offer. If PHP reaches a point where all core functions have a consistent naming format, I'll support removing short tags. We have to get rid of the old function names, though, otherwise people might get confused. Honestly, at this point you're just being a bit silly. No one has ever spoken out against BC breaks that have a positive impact on the language. Heck, if there isn't a negative impact to a BC break, I don't think anyone really cares, even if there isn't a positive one. There also isn't some slippery slope out there where if we allow short tags to remain we'll suddenly return to all out chaos where we don't continue to attempt to improve the language. "with all the things combined - short tags, that and that inconsistency not being removed" That reminds me of a baseball statistic. Hank Aaron and his brother Tommie combined to hit the most home runs among brothers: 768. Hank Aaron hit 755 of those. For those that don't follow baseball, only Barry Bonds has hit more home runs than Hank Aaron. Short tags are kind of like Tommie Aaron when it comes to the negative perceptions people have of the language. Getting rid of them really won't make that much of a difference.
> > -- > Peter Kokot >
-- Chase Peeler chasepeeler@gmail.com

Robert Korulczyk

7 years ago
> Many people have talked about the potential impacts of keeping short tags. > I have yet to see anyone give an actual example where they have been > negatively impacted by their existence. I've given you my personal story of > how removing them will negatively impact my company. I welcome anyone that > can provide an actual incident where the existence of short tags hurt them, > or, the continued existence is likely to have a large negative impact on > them in the future.
I was bitten by short open tags. Despite the "no short open tag" policy in our app, one occurrence of `<?` slipped through code review. It was in email template so it was quite hard to notice on production. Especially that short open tags were disabled only on CLI, so we had code leak only in emails sent by cron. It took over a month to notice that bug. You may be concerned about people abandoning PHP due to BC breaks, I'm more concerned about people abandoning PHP because of issues like this. It gives me the impression that the language wants to hurt you... Regards, Robert Korulczyk

Arvids Godjuks

7 years ago
чт, 8 авг. 2019 г. в 17:56, Robert Korulczyk <robert@korulczyk.pl>:
> > Many people have talked about the potential impacts of keeping short > tags. > > I have yet to see anyone give an actual example where they have been > > negatively impacted by their existence. I've given you my personal story > of > > how removing them will negatively impact my company. I welcome anyone > that > > can provide an actual incident where the existence of short tags hurt > them, > > or, the continued existence is likely to have a large negative impact on > > them in the future. > > I was bitten by short open tags. Despite the "no short open tag" policy in > our app, one occurrence of `<?` slipped through code review. It was in > email template so it was quite hard to notice on production. Especially > that short open tags were disabled only on CLI, so we had code leak only in > emails sent by cron. It took over a month to notice that bug. > > You may be concerned about people abandoning PHP due to BC breaks, I'm > more concerned about people abandoning PHP because of issues like this. It > gives me the impression that the language wants to hurt you... > > > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
I'd say this is not really a language concern and more tooling and testing problem. It's a class of a genuine mistake everybody does from time to time - be it wrong PHP tag, HTML tag or closing } added on the wrong line resulting in a logical error.
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

Robert Korulczyk

7 years ago
> I'd say this is not really a language concern and more tooling and testing problem. It's a class of a genuine mistake everybody does from time to time > - be it wrong PHP tag, HTML tag or closing } added on the wrong line resulting in a logical error.
This is a direct consequence of the language having settings that cause the same code to be interpreted (and works perfectly fine) in one environment and be displayed in other (without any warning). This is not the same as a typo in HTML tag or logical error in code. This is literally a tool for shooting yourself in the foot - it exists, but no one should use it. And it is still really easy to use it by accident. For example, this is what PhpStorm generates when you try to inline-comment tag with short echo: <?//= 'test' ?> Regards, Robert Korulczyk

Thomas Hruska

7 years ago
On 8/8/2019 3:26 AM, Côme Chilliet wrote:
> Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit : >> Pretty much everyone (if not actually >> everyone) that is against this RFC has stated that they don't actually use >> short tags, and do not advocate that anyone else use them either. > > This is what bugs me, the counter argument page from Zeev states «I never use short tags in any PHP code that I write, and as far as I recall - I never have. », > and at the same time «put hundreds of thousands of people through additional pain when upgrading.» > > Is there any data that support the theory that hundreds of thousands of people use short tags? > > Did anyone in this discussion stated that he was using them?
I used to use them extensively right up until the first RFC passed (e.g. CLI scripts, personal web apps, and some production systems). Had several thousand references to resolve but I'm off them now, whichever way this second RFC round goes. Other people chimed in that they use them too in "legacy production systems." Open source userland development demands the long open tag. So any scans of open source, public repos is going to be skewed heavily against actual use of short open tags. You simply can't rely on Composer or GitHub stats to show real-world usage numbers in this instance. So, yeah, people use them. Also, just because a lawyer, a lobbyist, or an ambassador are themselves unaffected by some issue doesn't mean they can't represent a class of an underserved population to bring forth awareness, justice, or action. In many cases, they are in better positions with sufficient contacts to reach the right people to bring forth such things that would otherwise never come to light.
-- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/

Bishop Bettini

7 years ago
On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> wrote:
> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
I voted "yes" for removal. <? is a security risk. If your code uses <?, then your code is liable to leak, based entirely on a setting potentially out of your control. As Robert Korulczyk's example illustrates, even within the same organization, misconfigurations can have hidden and drastic consequences. <? is a security risk today, just as much as it was then. Remember in 2007 when Facebook's source code leaked precisely because of this [1]? Much has been said about this being a "portability" issue. I think that's overly specific. The core issue is "fallibility". You can globally configure the language to stop recognizing itself as a language. That's weird and unexpected. So much so, that no one gives due thought to this, and we end up with security disasters. PHP.net has opined, for years, that <? is bad[2]. It's time to act. So much else breaks at the 8.0 boundary, let's do it all at once. If anyone needs to justify the effort, let them say "<? is a security hole". [1]:https://techcrunch.com/2007/08/11/facebook-source-code-leaked/ [2]:https://www.php.net/manual/en/language.basic-syntax.phptags.php

Zeev Suraski

7 years ago
On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote:
> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> wrote: > > > The voting for the "Deprecate short open tags, again" [1] RFC has begun. > > It is expected to last two (2) weeks until 2019-08-20. > > > > A counter argument to this RFC is available at > > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > > > Best regards > > > > George P. Banyard > > > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > > <? is a security risk today, just as much as it was then. Remember in 2007 > when Facebook's source code leaked precisely because of this [1]? >
Where's the evidence that it was precisely or even remotely because of this? Literally all of the PHP code leaks I've come across over the years had to do with a misconfigured Web server - e.g., load Apache without properly setting up handling for .php files, or having things like .inc files not blocked from HTTP access. As we deprecate short_tags, should we consider deprecating all SAPIs, and roll our own high-performance Web server into PHP? That's the only way to truly do away with the main vector for PHP source code leakage.
> > Much has been said about this being a "portability" issue. I think that's > overly specific. The core issue is "fallibility". You can globally > configure the language to stop recognizing itself as a language. That's > weird and unexpected. So much so, that no one gives due thought to this, > and we end up with security disasters. >
Except these are so uncommon and rare (I'm not aware of a single one, which doesn't mean there weren't any - but that they're not very common at all), that perhaps, just perhaps, it's a bit of an exaggeration to present them as a clear and present danger. PHP.net has opined, for years, that <? is bad[2]. This is the opinion of the person who wrote this document. I'm sure many agree with him - but there's no person named 'PHP.net' that can opine on things. That said - if you think people read the manual and are aware that this is discouraged and act accordingly - it's all the more reason to not care about this issue. If they don't, well, then it doesn't mean much that it's written over there. I personally don't think too many people read the manual on PHP's opening tags (I have absolutely no data to back this gut feeling up - it's just my gut feel).
> It's time to act. So much > else breaks at the 8.0 boundary, let's do it all at once.
The "we're breaking things so badly anyway, let's break'm some more" argument has been refuted many times on this list. First, I don't think we're breaking anything really badly in PHP 8. And secondly, this remains as bad a reason as it's ever been to break stuff. Breakage is not binary - it accumulates. The more you have of it - the more difficult it is to migrate, and the slower is the migration.
> If anyone needs > to justify the effort, let them say "<? is a security hole". >
It's a security hole in the exact same level that httpd.conf is a security hole. Yes, misconfiguring your Web server can have severe consequences. Thankfully, it's not nearly that big of a Thing for us to be concerned about. Zeev

Zeev Suraski

7 years ago
On Thu, Aug 8, 2019 at 10:35 PM Zeev Suraski <zeev@php.net> wrote:
> > > On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote: > >> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> wrote: >> >> > The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> > It is expected to last two (2) weeks until 2019-08-20. >> > >> > A counter argument to this RFC is available at >> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> > >> > Best regards >> > >> > George P. Banyard >> > >> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> >> <? is a security risk today, just as much as it was then. Remember in 2007 >> when Facebook's source code leaked precisely because of this [1]? >> > > Where's the evidence that it was precisely or even remotely because of > this? >
I'd like to add that looking at the source code[1] from the leaks, it appears to be using long tags - which means that if it is authentic - short tags were not the source of the leak. Also, there was a Perl leak[2] from Facebook as well. It's a bit difficult to blame short tags for that one. Zeev [1] https://gist.github.com/nikcub/3833406 [2] https://gist.github.com/philfreo/7257723

Chase Peeler

7 years ago
On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski <zeev@php.net> wrote:
> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote: > > > On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> > wrote: > > > > > The voting for the "Deprecate short open tags, again" [1] RFC has > begun. > > > It is expected to last two (2) weeks until 2019-08-20. > > > > > > A counter argument to this RFC is available at > > > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > > > > > Best regards > > > > > > George P. Banyard > > > > > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > > > > <? is a security risk today, just as much as it was then. Remember in > 2007 > > when Facebook's source code leaked precisely because of this [1]? > > > > Where's the evidence that it was precisely or even remotely because of > this? Literally all of the PHP code leaks I've come across over the years > had to do with a misconfigured Web server - e.g., load Apache without > properly setting up handling for .php files, or having things like .inc > files not blocked from HTTP access. > As we deprecate short_tags, should we consider deprecating all SAPIs, and > roll our own high-performance Web server into PHP? That's the only way to > truly do away with the main vector for PHP source code leakage. > > > > > > Much has been said about this being a "portability" issue. I think that's > > overly specific. The core issue is "fallibility". You can globally > > configure the language to stop recognizing itself as a language. That's > > weird and unexpected. So much so, that no one gives due thought to this, > > and we end up with security disasters. > > > > Except these are so uncommon and rare (I'm not aware of a single one, which > doesn't mean there weren't any - but that they're not very common at all), > that perhaps, just perhaps, it's a bit of an exaggeration to present them > as a clear and present danger. > > PHP.net has opined, for years, that <? is bad[2]. > > > This is the opinion of the person who wrote this document. I'm sure many > agree with him - but there's no person named 'PHP.net' that can opine on > things. > That said - if you think people read the manual and are aware that this is > discouraged and act accordingly - it's all the more reason to not care > about this issue. If they don't, well, then it doesn't mean much that it's > written over there. I personally don't think too many people read the > manual on PHP's opening tags (I have absolutely no data to back this gut > feeling up - it's just my gut feel). > > > > It's time to act. So much > > else breaks at the 8.0 boundary, let's do it all at once. > > > The "we're breaking things so badly anyway, let's break'm some more" > argument has been refuted many times on this list. First, I don't think > we're breaking anything really badly in PHP 8. And secondly, this remains > as bad a reason as it's ever been to break stuff. > > Breakage is not binary - it accumulates. The more you have of it - the > more difficult it is to migrate, and the slower is the migration. > > > > If anyone needs > > to justify the effort, let them say "<? is a security hole". > > > > It's a security hole in the exact same level that httpd.conf is a security > hole. Yes, misconfiguring your Web server can have severe consequences. > Thankfully, it's not nearly that big of a Thing for us to be concerned > about. > > We need to get rid of the display_errors ini directive as well. It
definitely shouldn't default to "1" or be set to "1" in the sample files distributed with PHP. I would think this is a much greater security risk than short tags. While we're at it, we need to get rid of the ability to even set custom error handlers. If a programmer doesn't use that correctly, they could still end up exposing error messages that contain sensitive data.
> Zeev >
-- Chase Peeler chasepeeler@gmail.com

Bishop Bettini

7 years ago
On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski <zeev@php.net> wrote:
> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote: > >> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> wrote: >> >> > The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> > It is expected to last two (2) weeks until 2019-08-20. >> > >> > A counter argument to this RFC is available at >> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> > > > If anyone needs to justify the effort, let them say "<? is a security >> hole". >> > > It's a security hole in the exact same level that httpd.conf is a security > hole. Yes, misconfiguring your Web server can have severe consequences. > Thankfully, it's not nearly that big of a Thing for us to be concerned > about. >
No, not even close to the same level. If my web server's misconfigured, (ALL) of my code's exposed. It's trivial to write a test to prove that my web server is properly serving PHP files. But if PHP's misconfigured, (all OR some OR none) of my code's exposed. The only way to decide is to literally check everything. That's why I highlighted Robert Korulczyk's case study: only a particular code path in a particular environment had the problem. The status quo enables deployments to fail insecurely. <? $dbpassword = "secret"; is a trap waiting to spring. I would rather require ten thousand people secure their environment by running a script, than risk a single person exposing their credentials for all to steal. I challenge everyone who's voted no to consider this balance.

Reinis Rozitis

7 years ago
> -----Original Message----- > From: Bishop Bettini [mailto:bishop@php.net] > > That's why I highlighted Robert Korulczyk's case study: only a particular code path in a particular environment had the problem. > > The status quo enables deployments to fail insecurely. <? $dbpassword = > "secret"; is a trap waiting to spring. I would rather require ten thousand > people secure their environment by running a script, than risk a single person > exposing their credentials for all to steal. > > I challenge everyone who's voted no to consider this balance.
If the initial RFC would have been accepted as is (without the later proposed changes after the lengthy discussion) you would have sprung the same "trap" as in that particular case study - code would be exposed. Argument for "only a particular code path in a particular environment" is somewhat weak because in that case why does even ' .user.ini' feature exists (especially in apache sapi where you can even do engine = 0) as it also can lead to wildly different language behaviour? rr

Robert Korulczyk

7 years ago
> Argument for "only a particular code path in a particular environment" is somewhat weak because in that case why does even ' .user.ini' feature exists (especially in apache sapi where you can even do engine = 0) as it also can lead to wildly different language behaviour?
Can you give an example where using `.user.ini` may create unexpected and hard to notice code leaks? Regards, Robert Korulczyk

Reinis Rozitis

7 years ago
> -----Original Message----- > From: Robert Korulczyk [mailto:robert@korulczyk.pl] > > > Can you give an example where using `.user.ini` may create unexpected and hard > to notice code leaks?
I did mention such example with the 'engine' setting ( https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik it's sapi specific) but technically it can happen just in one "hard to notice" subdirectory/tree. Note that atm short_tags are by default enabled and the disable happens only in php(-cli).ini so unless one throws the ini configuration files around willy nilly it is a deliberate decision from administrator. p.s. to clarify I'm not against changing the default value to disabled (to be consistent with the distributed ini-examples and (coding) recommendations) but I still don't understand what is the reason to deny for end-users the ability to change/re-enable this feature if they need it and choose so. But according to some emails for some reasons the existence of short tags now has turned out to be a major language future/feature blocker .. so go figure. rr

Robert Korulczyk

7 years ago
> I did mention such example with the 'engine' setting ( https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik it's sapi specific) but technically it can happen just in one "hard to notice" subdirectory/tree.
This does not explain how someone could use that feature *by accident*. I gave an example where you can use short open tags by accident, and it is really easy (the most popular IDE sometimes generates code with short open tags) and hard to notice (it is not easy to spot a difference between `<?` and `<?php`). How can you compare this to situation when you create a separate file with an explicit directive to disable PHP engine, and then be surprised that code is not executed? Regards, Robert Korulczyk

Reinis Rozitis

7 years ago
> This does not explain how someone could use that feature *by accident*. I gave > an example where you can use short open tags by accident, and it is really easy > (the most popular IDE sometimes generates code with short open tags) and hard > to notice (it is not easy to spot a difference between `<?` and `<?php`). How can > you compare this to situation when you create a separate file with an explicit > directive to disable PHP engine, and then be surprised that code is not executed?
Disabling short tags now is done with "an explicit directive" (there has to be a specific ini file with a specific setting 'short_open_tag = 0'). Isn't this the same "situation when you create a separate file with an explicit directive"? If a coder (or IDE) has written '<?', '<%' or by accident any other tag unless tested the effect (a part of code not being parsed/executed) will be exactly the same if the feature suddenly disappeared (unless the additional checks in the 'v2 RFC' which on the other hand would make the engine a tiny bit slower but probably have to be implemented to avoid such accidents). rr

Robert Korulczyk

7 years ago
> Disabling short tags now is done with "an explicit directive" (there has to be a specific ini file with a specific setting 'short_open_tag = 0'). > Isn't this the same "situation when you create a separate file with an explicit directive"?
No, it's not. `php.ini` is outside of project responsibility - as a developer you don't really configure this in any way, your application does not have any explicit directive to disable/enable short open tags. You just accidentally using feature that could lead to code leak. In your example with `engine` directive you explicitly disable PHP engine by creating dedicated file for that purpose - there is no way do to this by accident and then does not notice it.
> If a coder (or IDE) has written '<?', '<%' or by accident any other tag unless tested the effect (a part of code not being parsed/executed) will be > exactly the same if the feature suddenly disappeared (unless the additional checks in the 'v2 RFC' which on the other hand would make the engine a > tiny bit slower but probably have to be implemented to avoid such accidents).
At least the this behavior will be consistent - you will not have cases when code works fine on one environment and leak on another. Regards, Robert Korulczyk