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

2019-08-14 Thread Robert Korulczyk
> Good for you! Come take a stab at my legacy project. It's horrendous. We have 
> some files where using PhpStorm's automatic formatting actually caused
> stuff to break. So, you can see why I might be a little reticent to depend on 
> an automated tool to change my php tags. I'll let you start with a 12k+
> line file of spaghetti code. This file contains a lot of functions (not OO) 
> used across the legacy parts of the application. As such, it's included at
> the top of pretty much every PHP page. So, make sure you don't leave a typo, 
> because it'll break the entire application! 

I know how painful could be maintaining legacy code, but did you tried to run 
php-cs-fixer against this 12k+ file with PHP-spaghetti and report some
actual issues? You're spending time theorizing how automated tool can break 
your legacy code, but it would be far more productive if you spend it on
actual tests - this would give us very valuable insights how serious this 
problem is. Right now these are nothing more than *speculations* based on
usage of *completely different tool* for *completely different task*. Please, 
don't treat it as some hard argument.

> While you are at it, you can explain to my executive team (I don't work for a 
> software company) why it's worth putting in the time to modify all
> these "don't touch unless it's an emergency" legacy files to upgrade PHP when 
> the current version seems to be working fine from their perspective.

Sure. It would be something like: "Hey, it's *emergency*!" ;)

> That's another difference I've seen from the two sides of the argument. Those 
> in favor of removing them usually say things like "It doesn't seem like
> a big deal to me" or "I converted a project and it was really easy" or 
> "People shouldn't be using short tags anyway, so who cares." While those
> against removing them usually say things like "I can see how this could be a 
> huge problem for a large number of users" or "This could definitely block
> a lot of people from upgrading in a timely manner." 

This is one side of the coin. I'll show you another: I gave a real-world 
example that short open tag could lead to serious fuckup and be undetected
for quite a long time. I also gave an example of how easy is to accidentally 
introduce short open tags in your code. There are other people who also
treats short open tags as dangerous feature and security issue. Despite this, I 
can read multiple times that "short open tags are no-issue" or "there
is no gain in removing short open tags". In counterargument for this RFC you 
can read that "Deprecating short tags, as illustrated in this
counterargument, brings us *virtually no value at all*.".
There is no difference between both "camps" - both are focusing on their 
perspective and their arguments, while underestimating problems and arguments
of other "camp". For you existence of short open tags is minor issue, for me 
migrating to `http://www.php.net/unsub.php



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

2019-08-14 Thread Claude Pache


> Le 14 août 2019 à 19:01, Olumide Samson  a écrit :
> 
> This was exactly my reason for participating in this discussion, if such
> simple BC break encounters fierce and lengthy-weighted resistance, I'm not
> sure there will ever be a BC break, only additions without a necessary
> cleanup.
> 
> That's just like, there's a precedent to resist all kinds of BC break
> simply because there's no positive impact on the change.

No, BC breaks and cleanups have been regularly implemented in the past, and 
that will continue. Two recent examples among several others:

https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase 

https://wiki.php.net/rfc/ternary_associativity 


About short-open tags. Many people thought that this particular BC break or 
cleanup was not useful enough. That’s all.

—Claude

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

2019-08-14 Thread Olumide Samson
On Wed, Aug 14, 2019, 5:23 PM Robert Korulczyk  wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come
> off that way to me as well. I've definitely viewed most of what you've said
> in
> > that manner.
>
> I guess we're in some kind of limbo where half of the people do not
> consider problems which short open tags create as serious, and other half
> does not
> consider BC break implications as serious.
> I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal
> with.


So for me "it will be so hard to upgrade" arguments are also exaggerated,
> and that's why I'm concerned about future BC breaks - if such simple
> change encounters such fierce resistance, then what kind of BC break can
> be accepted?
>
This was exactly my reason for participating in this discussion, if such
simple BC break encounters fierce and lengthy-weighted resistance, I'm not
sure there will ever be a BC break, only additions without a necessary
cleanup.

That's just like, there's a precedent to resist all kinds of BC break
simply because there's no positive impact on the change.

Millions of code can be migrated through many existing libraries in short
time frame to comply with the short tag depreciation.

I think the resistance is actually the reason this discussion(thread) gets
this lengthy.

At the end of all, we either have it or leave it.
Happy coding.

>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

2019-08-14 Thread Chase Peeler
On Wed, Aug 14, 2019 at 12:22 PM Robert Korulczyk 
wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come
> off that way to me as well. I've definitely viewed most of what you've said
> in
> > that manner.
>
> I guess we're in some kind of limbo where half of the people do not
> consider problems which short open tags create as serious, and other half
> does not
> consider BC break implications as serious.
>
No, we're not. Only people that are in favor of removing short tags seem to
be making this RFC a referendum on BC breaks in general. We understand
there is a security risk. As others have pointed out, it's a rather minor
one. Code gets deployed with short tags onto a server that has short tag
support turned off. The solution is to turn short tags back on. It's a
setting that can be turned on/off at any level, so, just throw it in your
.htaccess file. If you use windows and IIS like me, you can set it in your
registry. Not ideal, but, it works. If there was no way to quickly enable
short tag support, the discussion might be different. Since there is, the
security implications, while they exist, are mitigated.

It's further mitigated by the fact that almost everyone writing portable
code is not using short tags to begin with. This means the odds of me
downloading a 3rd party library that uses short tags is pretty slim. If I
actually do some due diligence (look at the source code, stick to something
actively maintained, something with good reviews, etc) it's even slimmer.
If it's code I'm writing myself, then, I should no better than to write
code with short tags if I'm going to deploy it to a server that doesn't
support them (or that I don't have control over).

As Zeev has mentioned many times, in retrospect, short tags probably should
have never been supported. If they never had been supported, then there
wouldn't be any case for adding support for them now. That doesn't change
the fact that they have been support for 20 years, and removing support for
them now has huge implications for a lot of non-portable legacy code.That
is compared with a security issue, that while it does exist, is very
unlikely to occur for anyone using a modicum of common sense, and can
easily be resolved if it does.


> I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal
> with. So for me "it will be so hard to upgrade" arguments are also
> exaggerated, and that's why I'm concerned about future BC breaks - if such
> simple
> change encounters such fierce resistance, then what kind of BC break can
> be accepted?
>
> Good for you! Come take a stab at my legacy project. It's horrendous. We
have some files where using PhpStorm's automatic formatting actually caused
stuff to break. So, you can see why I might be a little reticent to depend
on an automated tool to change my php tags. I'll let you start with a 12k+
line file of spaghetti code. This file contains a lot of functions (not OO)
used across the legacy parts of the application. As such, it's included at
the top of pretty much every PHP page. So, make sure you don't leave a
typo, because it'll break the entire application!

While you are at it, you can explain to my executive team (I don't work for
a software company) why it's worth putting in the time to modify all these
"don't touch unless it's an emergency" legacy files to upgrade PHP when the
current version seems to be working fine from their perspective.

That's another difference I've seen from the two sides of the argument.
Those in favor of removing them usually say things like "It doesn't seem
like a big deal to me" or "I converted a project and it was really easy" or
"People shouldn't be using short tags anyway, so who cares." While those
against removing them usually say things like "I can see how this could be
a huge problem for a large number of users" or "This could definitely block
a lot of people from upgrading in a timely manner." I'm one of the few
people I've seen that is against removing short tags AND has provided
examples in their own code bases of how it will impact them in a negative
way. Most of those against it have based their opinion on knowing that
others will be negatively impacted by this, even if they personally won't.
Honestly, if it was just my code that was the concern, I wouldn't be as
vocal. I can suck it up and fix things. I can cut through the red tape and
get it done at some point so we can upgrade. I'm vocal on this because I
know there are other developers out there dealing with a legacy code base
like mine, if not worse, that might not be able to just bite the bullet and
get it done.


> Regards,
> Robert Korulczyk
>


-- 
Chase Peeler
chasepee...@gmail.com


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

2019-08-14 Thread Robert Korulczyk
> While possibly a bit hyperbolic, most of the arguments basically come off 
> that way to me as well. I've definitely viewed most of what you've said in
> that manner.

I guess we're in some kind of limbo where half of the people do not consider 
problems which short open tags create as serious, and other half does not
consider BC break implications as serious.
I already migrated some quite big legacy apps from `http://www.php.net/unsub.php



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

2019-08-14 Thread Chase Peeler
On Wed, Aug 14, 2019 at 10:49 AM Robert Korulczyk 
wrote:

> > This discussion has gone out of sanity levels the moment people started
> to state that short tags is one (of the many)
> > things PHP has why new programmers and companies don't pick the language
> or why colleagues laugh at you and is a
> > blocker of new bright future etc. and now in this moment this is a do or
> die situation otherways next year everyone
> > will be writing in javascript.
>
> No one said that (except you).
>
> While possibly a bit hyperbolic, most of the arguments basically come off
that way to me as well. I've definitely viewed most of what you've said in
that manner.


> But current reaction for this RFC could be depressing. I'm using PHP for
> quite a long time and I really hoped that someday we'll be able to get rid
> of
> all (or at least the most of them) the traps and annoying little things
> from the old days. That doesn't sound realistic anymore...
>
> This is exactly what we're talking about. You act as if leaving short tags
in PHP means nothing will ever get cleaned up. That there is absolutely no
reason at all we might want to consider leaving them, so, the fact that we
are is just a signal that no one is willing to entertain the idea of BC
breaks for anything ever.

>
> > Except there are 4-5 functions which do the same not to mention ``
> backtick syntax (can't there be an accident mixing those with single
> quotes?).
>
> I was talking about all these functions that allows to execute shell
> commands. What is the point of disabling only one of them? I thought that
> the
> problem is in functionality, not in the name :P
>
> Or, maybe, it's just that the negative consequences of removing those
functions doesn't justify the positives that would be gained? That's the
whole argument with short tags. It's not "Short tags are wonderful!" or
"There is absolutely NOTHING bad about short tags and how they are
currently handled." We've just been saying that while there are negatives,
they are negatives that have existed for 20 years without causing large
scale issues. The issues they cause do not justify removing them and the
impact it will have on existing developers and code bases. It causes a
large amount of difficulty for many people to upgrade while only solving a
possible security issue that is actually pretty easy to avoid.

Honestly, while I didn't have a vote, if the RFC didn't include language
about actually removing short tag support in PHP 9, I would have encouraged
people to support it. I have no issues with helping push people towards not
using short tags, and then at some point in the future discussing whether
to remove support or not.

In the end, what I see is one side (those for keeping short tag support)
readily admitting that there are issues with short tags, but they aren't
outweighed by the negatives. I see the other side (those for removing short
tag support) acting as if there were absolutely no negatives at all to
removing them. You even said exactly that: "Since we don't have any good
cause to leave it be, let it go." They also inflate the issues with short
tags to hyperbolic levels, making them into a huge security implication,
the driving force behind anti-PHP sentiment, and the barrier to new
developers picking up the language. That makes it impossible to have a
reasoned discussion on the argument. It's like one side is saying "I know
fire is dangerous, but I think it's a good idea to have some matches handy
just in case." And the other side saying "No, if we have matches no one
will ever come to our house and all of our neighbors will laugh at us and
we'll almost definitely burn the house down." Even though you've had
matches in the house for the last 20 years without any issues.


> >> `` is intended usage of short open tags.
> >
> > On this I could also say that recommendations are to store all
> credentials outside webroot,
>
>
> I'm afraid you don't understand the problem. Having such code outside of
> webroot does not help you much if this file will be included from another
> file (which uses ` password is just the simplest example - single non-working `if` can lead to
> a
> wide range of bugs with serious consequences, far beyond code leak.
>
> What about the display_errors ini directive? That seems like a security
risk as well, since error messages can contain sensitive information. I
know keeping/removing it isn't mutually exclusive with keeping/removing
short tags. I'm just curious why it's never mentioned by anyone that
suddenly is so concerned about the security implications of short tags.

>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com


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

2019-08-14 Thread Robert Korulczyk
> This discussion has gone out of sanity levels the moment people started to 
> state that short tags is one (of the many) 
> things PHP has why new programmers and companies don't pick the language or 
> why colleagues laugh at you and is a 
> blocker of new bright future etc. and now in this moment this is a do or die 
> situation otherways next year everyone 
> will be writing in javascript.

No one said that (except you).

But current reaction for this RFC could be depressing. I'm using PHP for quite 
a long time and I really hoped that someday we'll be able to get rid of
all (or at least the most of them) the traps and annoying little things from 
the old days. That doesn't sound realistic anymore...


> Except there are 4-5 functions which do the same not to mention `` backtick 
> syntax (can't there be an accident mixing those with single quotes?).

I was talking about all these functions that allows to execute shell commands. 
What is the point of disabling only one of them? I thought that the
problem is in functionality, not in the name :P


>> `` is intended usage of short open tags.
> 
> On this I could also say that recommendations are to store all credentials 
> outside webroot, 


I'm afraid you don't understand the problem. Having such code outside of 
webroot does not help you much if this file will be included from another
file (which uses `http://www.php.net/unsub.php



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

2019-08-14 Thread Reinis Rozitis
> Please, let's keep this discussion at some level of sanity... You basically 
> need
> stick to static HTML if you're considering possibility of such exec() usage 
> as a
> security issue.

This discussion has gone out of sanity levels the moment people started to 
state that short tags is one (of the many) things PHP has why new programmers 
and companies don't pick the language or why colleagues laugh at you and is a 
blocker of new bright future etc. and now in this moment this is a do or die 
situation otherways next year everyone will be writing in javascript.


> 1. exec-like functions have their purpose without any straight-forward 
> alternative, while ` `` is intended usage of short open tags.

On this I could also say that recommendations are to store all credentials 
outside webroot, but again it also qualify as something different than by 
accident generated code in IDE, just to show that the "security issue" can be 
stretched however you like.


> You basically need stick to static HTML

Maybe. 
But let's end at this ..

rr




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



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

2019-08-14 Thread Chase Peeler
On Wed, Aug 14, 2019 at 7:03 AM Olumide Samson 
wrote:

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

The "shake-ups" that will draw people to PHP are the new features, the
majority of which don't require BC breaks and were listed earlier in this
thread. Go find a group of anti-PHP developers. Tell them how wonderful PHP
9 is going to be. When they ask why, tell them "We've got rid of short
tags!" and see how they react. Now, find another group of anti-PHP
developers. Tell them how wonderful PHP 9 is going to be. Tell them it will
have generics, enums, union types, and JIT. Also mention that short tags
will still be allowed. See how they react. They might not really care, and
still not like PHP, but I can guarantee you it won't be because short tags
still exist.


-- 
Chase Peeler
chasepee...@gmail.com


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

2019-08-14 Thread Robert Korulczyk
W dniu 14.08.2019 o 14:14, Reinis Rozitis pisze:
> Depends on how you look at if exec($_GET['param']) is a language 
> responsibility or programmers?

Please, let's keep this discussion at some level of sanity... You basically 
need stick to static HTML if you're considering possibility of such exec()
usage as a security issue.

They're at least 3 main deferences between short open tags and exec-like 
functions:

1. exec-like functions have their purpose without any straight-forward 
alternative, while `` is intended usage of short open tags.
3. Because of point 2, there is no IDE or editor which will generate code like 
`exec($_GET['param'])`, while there is at least one popular IDE which
will generate code with short open tags.


Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



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

2019-08-14 Thread Reinis Rozitis
> Honestly, I don't see how allowing exec/passthru/proc_open is a security risk.
> These are just tools. We're talking about programming language - if you're
> running PHP script as user X you should expect that it could do anything that 
> user
> X can do. If you don't trust this script, just don't run it

Depends on how you look at if exec($_GET['param']) is a language responsibility 
or programmers?

On the same level you can then expect that programmer X always uses ' https://www.php.net/manual/en/language.basic-syntax.phptags.php
> 
> "PHP also allows for short open tag  available if enabled using the short_open_tag php.ini configuration file 
> directive,
> or if PHP was configured with the --enable-short-tags option)."

Which is actually the other way around - enabled by default / disabled if 
configured via ini.

It feels most people who argue about the feature (are not in the burn it with 
fire and everyone who uses them should just go away) would be fine (enough) if 
it aligned to what's written in the documentation and then make deliberate 
decision to enable those.

rr 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



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

2019-08-14 Thread Robert Korulczyk
> Sure those are important - I was just pointing out that the "security card" 
> is questionable since the language has more dangerous features
> which ask for the user to be careful and responsible about them rather than 
> making everything foolproof and accident-free.

Honestly, I don't see how allowing exec/passthru/proc_open is a security risk. 
These are just tools. We're talking about programming language - if
you're running PHP script as user X you should expect that it could do anything 
that user X can do. If you don't trust this script, just don't run it
- disabling exec/passthru/proc_open does not change much since PHP is powerful 
enough to hurt you badly without executing any shell commands.

If you think that disabling exec function will protect you from malicious 
scripts, then you have real security problem related directly to your
environment and completely unrelated to PHP (it is OS responsibility to 
disallow access to part of the system, which should not be accessed by a
particular program).

> Considering the current RFCs has it really been decided as "don't use it" 
> (when/where?)? 

https://www.php.net/manual/en/language.basic-syntax.phptags.php

"PHP also allows for short open tag http://www.php.net/unsub.php



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

2019-08-14 Thread Olumide Samson
On Wed, Aug 14, 2019, 11:24 AM Peter Kokot  wrote:

> On Wed, 14 Aug 2019, 12:09 Reinis Rozitis,  wrote:
>
> > > It is surprising how thing that is considered by one to be a security
> > risk, is treated
> > > as nothing relevant by others. This dichotomy is quite disturbing - in
> > what case
> > > removing security risk is "no real gain"?
> >
> > It's questionable that a misconfigured environment is a "security" risk
> > caused by language rather than ignorance of the administrator.
> >
> > On that matter you could ask why are all the exec/passthru/proc_open etc
> > functions/features are allowed by default while every other guide on
> > hardening web suggests those to be disabled (added to disable_functions)?
> > I would bet there have been a lot more (actual) security breaches because
> > of unsanitized/unescaped parameters to those.
> >
> > Just to repeat some other people - there are a lot other things to work
> on
> > than this.
> >
> > rr
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> Appologies if these short tags are bumped so many times and cause so much
> issues but we are at the very starting discussions of PHP 8 also. Major
> version, where breaking thing was supposed to be possible. So that is one
> of the reasons why this and similar cleanups are mentioned in the first
> place. With closing the door to even talk and work on cleanups, or being
> ashamed of it, or bully others because they want to have a better structure
> with using PHP 8+, nothing good can come out of it.
>
> >
> >
> >
>
I'm with you on this PHP 8 argument.
I think many of this popular languages that's making my PHP professional
coding look like kids play make sure their major version shake up many old
things, to cleanup old things that's either better not released or would
cause some developers to write environment-tied programs.
Since we don't have any good cause to leave it be, let it go.

Let the user land developers see PHP as a major language they are hoping
for.

Currently, it's easy to learn, use, break or make.
Let them see the intern devs are strict and mature enough to break things
when needed and when possible.

Break it off if it's not useful or would allow the possibility to write
environment tied code(where short tag is not a general idea) and what are
we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let
the world wow at the internals courage, focus and super ability to
implement what's needed. Why wait for a time, when we have little time?
Should we wait for cleanups until PHP 9 or PHP 10?
Im sure javascript would have moved on around that time as the same
language for web, mobile and desktop application, while PHP a major
language still keep in doing its stuff at the server side(and the user land
get booed as boring programmer who would have to learn multiple languages
to get a desktop, mobile and web application designed).

Please,clean up.

>


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

2019-08-14 Thread Reinis Rozitis
> This is about accidental usage of *language* feature, which *by design* can 
> lead to code leaks (so application bug, not misconfigured environment). 
> Clearly not a language problem that it has dedicated feature to shoot 
> yourself in the foot...
> 
> These methods have their purpose (pretty important BTW), short open tags is
> just "don't use it!!!" feature.

Sure those are important - I was just pointing out that the "security card" is 
questionable since the language has more dangerous features which ask for the 
user to be careful and responsible about them rather than making everything 
foolproof and accident-free.


Also it's not by design - the only way code can leak is when it has been using 
'http://www.php.net/unsub.php



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

2019-08-14 Thread Robert Korulczyk
W dniu 14.08.2019 o 12:09, Reinis Rozitis pisze:
> It's questionable that a misconfigured environment is a "security" risk 
> caused by language rather than ignorance of the administrator. 

This is not about misconfigured environment. This is about accidental usage of 
*language* feature, which *by design* can lead to code leaks (so
application bug, not misconfigured environment). Clearly not a language problem 
that it has dedicated feature to shoot yourself in the foot...

> On that matter you could ask why are all the exec/passthru/proc_open etc 
> functions/features are allowed by default while every other guide on
hardening web suggests those to be disabled (added to disable_functions)?

These methods have their purpose (pretty important BTW), short open tags is 
just "don't use it!!!" feature.


Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



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

2019-08-14 Thread Peter Kokot
On Wed, 14 Aug 2019, 12:09 Reinis Rozitis,  wrote:

> > It is surprising how thing that is considered by one to be a security
> risk, is treated
> > as nothing relevant by others. This dichotomy is quite disturbing - in
> what case
> > removing security risk is "no real gain"?
>
> It's questionable that a misconfigured environment is a "security" risk
> caused by language rather than ignorance of the administrator.
>
> On that matter you could ask why are all the exec/passthru/proc_open etc
> functions/features are allowed by default while every other guide on
> hardening web suggests those to be disabled (added to disable_functions)?
> I would bet there have been a lot more (actual) security breaches because
> of unsanitized/unescaped parameters to those.
>
> Just to repeat some other people - there are a lot other things to work on
> than this.
>
> rr
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Appologies if these short tags are bumped so many times and cause so much
issues but we are at the very starting discussions of PHP 8 also. Major
version, where breaking thing was supposed to be possible. So that is one
of the reasons why this and similar cleanups are mentioned in the first
place. With closing the door to even talk and work on cleanups, or being
ashamed of it, or bully others because they want to have a better structure
with using PHP 8+, nothing good can come out of it.

>
>
>


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

2019-08-14 Thread Reinis Rozitis
> It is surprising how thing that is considered by one to be a security risk, 
> is treated
> as nothing relevant by others. This dichotomy is quite disturbing - in what 
> case
> removing security risk is "no real gain"?

It's questionable that a misconfigured environment is a "security" risk caused 
by language rather than ignorance of the administrator. 

On that matter you could ask why are all the exec/passthru/proc_open etc 
functions/features are allowed by default while every other guide on hardening 
web suggests those to be disabled (added to disable_functions)?
I would bet there have been a lot more (actual) security breaches because of 
unsanitized/unescaped parameters to those.

Just to repeat some other people - there are a lot other things to work on than 
this.

rr


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



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

2019-08-14 Thread Robert Korulczyk
W dniu 14.08.2019 o 11:09, Christian Schneider pisze:
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
>>> The best counterargument I can give against "cleaning up" is that it takes 
>>> energy away from actual new features, even if it's just the mental energy 
>>> of monitoring and responding to long threads like this one.
>>
>> Code is like a garden. If there are unwanted weeds and nobody cleans
>> them up, the flowers don't shine and grow as they should.  Cleaning of
>> the weeds is just as important as new features. A bit less but
>> important.
> 
> Going with your analogy: Some things (like short open tags) are that 
> individual small flower in the corner of the garden which does not multiply. 
> We already spent way too much time discussing it, the rest of the garden 
> needs water and the gardeners are fighting over a dandelion. A bike-shed 
> discussion at its worst: No real gain but everybody has an opinion.
> Real cleaning up, now that's where it gets interesting. And those discussions 
> tend to be more productive even recently.
> 
> Oh and: I'm very much afraid the OP was trolling and succeeded in getting 
> people to react, so please, please let this particular thread die :-(
> 
> - Chris
> 
> 

It is surprising how thing that is considered by one to be a security risk, is 
treated as nothing relevant by others. This dichotomy is quite
disturbing - in what case removing security risk is "no real gain"?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



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

2019-08-14 Thread Peter Kokot
On Wed, 14 Aug 2019 at 11:09, Christian Schneider  wrote:
>
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
> >> The best counterargument I can give against "cleaning up" is that it takes 
> >> energy away from actual new features, even if it's just the mental energy 
> >> of monitoring and responding to long threads like this one.
> >
> > Code is like a garden. If there are unwanted weeds and nobody cleans
> > them up, the flowers don't shine and grow as they should.  Cleaning of
> > the weeds is just as important as new features. A bit less but
> > important.
>
> Going with your analogy: Some things (like short open tags) are that 
> individual small flower in the corner of the garden which does not multiply. 
> We already spent way too much time discussing it, the rest of the garden 
> needs water and the gardeners are fighting over a dandelion. A bike-shed 
> discussion at its worst: No real gain but everybody has an opinion.
> Real cleaning up, now that's where it gets interesting. And those discussions 
> tend to be more productive even recently.
>
> Oh and: I'm very much afraid the OP was trolling and succeeded in getting 
> people to react, so please, please let this particular thread die :-(
>
> - Chris

I'm sorry but until the RFC is still in voting phase, participants
should be welcome to express opinions. And the message by OP was
correct. PHP is having a lot of these old sins and they are standing
out, yes.


-- 
Peter Kokot

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



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

2019-08-14 Thread Christian Schneider
Am 14.08.2019 um 10:39 schrieb Peter Kokot :
>> The best counterargument I can give against "cleaning up" is that it takes 
>> energy away from actual new features, even if it's just the mental energy of 
>> monitoring and responding to long threads like this one.
> 
> Code is like a garden. If there are unwanted weeds and nobody cleans
> them up, the flowers don't shine and grow as they should.  Cleaning of
> the weeds is just as important as new features. A bit less but
> important.

Going with your analogy: Some things (like short open tags) are that individual 
small flower in the corner of the garden which does not multiply. We already 
spent way too much time discussing it, the rest of the garden needs water and 
the gardeners are fighting over a dandelion. A bike-shed discussion at its 
worst: No real gain but everybody has an opinion.
Real cleaning up, now that's where it gets interesting. And those discussions 
tend to be more productive even recently.

Oh and: I'm very much afraid the OP was trolling and succeeded in getting 
people to react, so please, please let this particular thread die :-(

- Chris


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php