> 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
> 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.
>
>
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
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
> 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,
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
> 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
> 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
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
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
> 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
> 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
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
> >
> 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
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
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
> 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
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
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
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
20 matches
Mail list logo
