> Yet again the PHP community doesn't care about security of its users, current
> and future, and just prefers the convenience of needing to type less
> characters and not go back fix some code for better design.
>
>
> Gina P. Banyard
If you describe it in such a dramatic fashion, then there
> I have worked with PHP for 14 years now and I know nothing about PEAR. It
> either says something about me or about PEAR.
Then the next logical question would be do you know what PECL is? :)
But to be short my point is - before attempting to get new function(ality) in
core it (seems to me)
> Which begs the question of a PHP Package for PHP. Some benefits:
>
> - Written in PHP, it will allow a much wider pool of contributors than the
scarce pool of C developers contributing to PHP source code.
Aren't this what frameworks are for (Laravel / Yii / Symfony / Zend etc)?
Or PEAR?
Like
> Oftentimes community discussions are happening in parallel to the internal
> discussions on the PHP reddit.
> As is the same for this discussion, reading it is often useful to get
> community input.
>
> Any type error should if you ask me. Unexpected types cause unexpected
> behavior, and the longer PHP will try to continue with assumptions of types
> and implicit casting, the bigger the damage can be. All this type juggling is
> headache material and the less I see of it, the better.
Sorry
> Last, regarding neutrality. This proposal is literally aimed at adopting
> more-
> neutral language. It's not a partisan move to say that harmful language
> should be avoided.
The problem (imo) is projecting/tying relations and social interactions (past
and present) between people onto
> The word "master" has 18 meanings in English, according to
> https://en.m.wiktionary.org/wiki/master - do you propose to outlaw those
> 17 of them that have nothing to do with slavery, too? What about master's
> degree, for example?
>
I wonder what will astronomers do with 'black hole' ..
> -Original Message-
> From: Mike Schinkel
>
> That is a utopian sentiment, but not valid in the corporate world that uses
> managed hosting because they are focused on operating their business and
> not on having to spend time, resources and management expertise in
> securing and running
> -Original Message-
> From: Benjamin Morel [mailto:benjamin.mo...@gmail.com]
>
>
> And we could change the RFC process to either:
>
> - require a 2/3 majority of votes *in each category*
> - *or *require a 2/3 majority in the *average of all three categories*
> - *or *give a weight to
> -Original Message-
> From: Benjamin Morel [mailto:benjamin.mo...@gmail.com]
>
> One gain that's very often overlooked on this list, is teaching a better PHP
> to
> new generations. It IS confusing if PHP has more than one way to do one thing,
Not directly related to this RFC but out of
> -Original Message-
> From: Mark Randall [mailto:marand...@php.net]
>
> On 06/10/2019 14:18, Reinis Rozitis wrote:
> > Since `` are used for literal strings (for poorly chosen reserved words as
> > field,
> table names (which happens from time to time)) in
> -Original Message-
> From: Olumide Samson [mailto:oludons...@gmail.com]
>
> it should be deprecated for exec usage since they both do same thing
With that logic This isn't high cost breaking changes coz it has a verifiable, ready
> alternative to upgrade to without huge Regex
> "It's like our company car still works, but it no longer tighter meets
> emissions
> standards so they won't let us take it into the city any more"
That's a very interesting way to describe error level changes of a language.
I wonder what happens when the manager asks - "What's with those guys
> 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
> 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
> 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
> 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
> 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
> -Original Message-
> From: Robert Korulczyk [mailto:rob...@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 (
> -Original Message-
> From: Bishop Bettini [mailto:bis...@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. "secret"; is a trap
> -Original Message-
> From: Brent [mailto:bre...@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,
> -Original Message-
> From: Côme Chilliet [mailto:c...@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
> First, short_open_tag is an ini setting that control core language syntax.
> 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
> of the deployment environment.
While this RFC is a
> -Original Message-
> From: Marco Pivetta [mailto:ocram...@gmail.com]
>
> Also a good chance to finally take a look at code that has been rotting in a
> hard
> drive for too much time.
It's an odd way of justifying a BC break by saying "you can write this
one-liner sed or use this
> A 68% majority which barely clears the 2/3 requirements for something as
> fundamental as that - with so many core devs against it - we'll deserve all
> the
> criticism that will be coming our way in 7.4/8.0 from end users wondering why
> we needlessly broke their apps and made migration a bit
> From: Robert Korulczyk [mailto:rob...@korulczyk.pl]
>
> Personally, I'm surprised by the controversy around this change. So far it
> was an
> obvious anti-pattern for me, and never seen anybody who was aware of the
> consequences of using http://www.php.net/unsub.php
> I would like to start the discussion about the deprecation of PHP's short open
> tags:
> https://wiki.php.net/rfc/deprecate_php_short_tags
Hi,
I did read the initial thread about this and now the RFC and it doesn't really
state what is the reason of removing the short tags besides this one
> who forces you to ext/mysql?
It's out of topic but obviously the code/software and products on the servers.
For me as a system administrator I have choice either to never upgrade (for
example https://w3techs.com/technologies/details/pl-php/all/all one can see the
rough rate of php version
> no idea what the state of PDO is
>
>
> http://blog.ulf-wendel.de/2008/php-new-network-traffic-cpu-and-memory-
> savings-with-mysqlnd/
>
>if(mysqli_options($this->conn, MYSQLI_OPT_INT_AND_FLOAT_NATIVE,
Thanks,
as we still partly (forced to) live in the "deprecated or moved to pecl"
?
[1] https://phpdelusions.net/pdo#returntypes
wbr
Reinis Rozitis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From: Michael Vostrikov
The problem is that these functions should be called everywhere manually,
and there is no error when these functions are not called.
And this RFC proposes a solution - call a function automatically.
Though you can use pecl/taint for that.
If anything imo it would make
Again, why can't we just bypass this whole argument by adding a configure
option? Something like --date.default_timezone=America/Los_Angeles? It
could then build that in so it'll assume that if there's no php.ini or if
it's just not set in there. Problem solved, everybody's use-case covered.
From: Patrick ALLAERT
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not part
of the proposed RFC and should certainly not happen.
I don't get what is the reason behind it?
Yes, the extension is old but it still works perfectly fine and even
outperforms the newer
Rewriting perfectly functional mysql code to use mysqli is not a trivial
move, just as are the problems of re-writing PHP5.2 code to work cleanly
on 5.4. ISP's are stuck between keeping customers - who are most likely
not even very computer literate - working while fighting the problems that
In short, this allows spawning a PHP-FPM pool on-demand with systemd
initializing the main socket.
What would be the advantage on using systemd instead of using FPMs native
'ondemand' process manager?
rr
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Let's start from the beginning.
How are you going to detect how much memory a thread consumes?
no ideas
There is an old patch in the Zends PAT directory http://devzone.zend.com/content/patch/pat38.txt (it reads the /proc/pid though or
fallbacks to getrusage).
Have used this for quite a
- See if the normal libevent or libev could handle all the needs and
not a patched copy anymore (or get with the libevent team)
Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external
libevent on system now.
- Adaptive process support (the major thing lacking)
Somewhat
Correct. Biggest lacking feature.
While this maybe a bit out of topic, but just out of curiosity why do you think that adaptive spawning is any good (trying to run
more processes in given time period than started) - stepping back to how apache operates with its prefork mechanism (iirc there
For example lighttpd according to NetCraft:
01.2007 lighttpd 172819
02.2007 lighttpd 702712
You should wait march, such a jump is suspect :)
--Pierre
Hello Pierre,
03.2007 lighttpd 1.399.786
http://survey.netcraft.com/Reports/0703/
This gives place 4, right behind Sun (if you skip
Andi Gutmans wrote:
Yeah but process limits are inherited after fork().
Well probably. But does there exists a configurable limit in php for that
(which was implemented by previos mentioned patch in 4.x branch)? As if the
child exceeds the limit it handles the last request and shuts down
Christopher Jones wrote:
I guess MySQL folks are also looking into Java like connection pooling:
http://krow.livejournal.com/487174.html
Besides there are some third-party solutions like SQLRelay
http://sqlrelay.sourceforge.net/
rr
--
PHP Internals - PHP Runtime Development Mailing List
Andi Gutmans wrote:
Don't the FastCGI processes inherit memory limits from their parent? (assuming
you're not running standalone FastCGI which almost
noone does).
Nope, the parent (master) process only keeps the track of active childs
(usually I spawn like 250 of them) and distributes the
Hello,
is there a chance that this will ever make in PHP5 (or othet future
releases) as base feature http://www.zend.com/zend/week/pat/pat48.txt
That is besides PHP_FCGI_MAX_REQUESTS to have also the posibility limit the
childs max memory usage/leak (PHP_FCGI_MAX_RAM_MB)
I'm asking about this
It will never replace the GD extension. Please read the whole thread
before making conclusions (btw, check out http://www.libgd.org).
I didnt mean that way nor as a conclusion, GD is still much faster and so on
(but thanks for the link/hint).
It was just an excuse why did I play with
I'm not sure that you are looking at the right place to solve the
problem. If the leaks are in phpinfo (or in memory allocated by php),
then maybe (really not sure).
But if the leaks are in IM as their extension does not use php memory
manage, it is not something fixable by php or anything else
Hello,
just a quick question - will the include_once() (Optimized require_once()
and include_once() by eliminating fopen(3) on second usage. (Dmitry))
optimisation fix in 5.2.0 backported also in PHP 4 tree (in 4.4.5 maybe?)
Theoretically speaking (havent checked the default funcs internal
No, no features will be back ported to PHP 4.4.
Although I dont see this as feature more like a fix (uneeded opens() stats()
on each call) still thank you for the fast reply.
p.s. lately the topics and discussions on internal list are pretty scarry..
starting with political issues and
47 matches
Mail list logo
