Should it be named php4ts?
Andrey
Quoting DvDmanDT [EMAIL PROTECTED]:
Should those really be built into php4ts.dll?
Derick Rethans [EMAIL PROTECTED] skrev i meddelandet
news:[EMAIL PROTECTED]
On Tue, 28 Jun 2005, Jani Taskinen wrote:
1.6MB timezonedb.h in ext/date/lib/ would be a
I agree that we need to improve the overall level of security in PHP,
but I am not sure that focusing on allow_url_fopen is very constructive.
There are far far more web sites that have these other unfiltered user
data issues than have url_fopen issues.
I agree with Rasmus. Remote URL
On Wed, 15 Jun 2005, Moriyoshi Koizumi wrote:
Hello,
On 2005/06/14, at 21:59, Derick Rethans wrote:
The following test is failing for everybody. This bug occurred after you
fixed the bug in report #29493. Can you please have a look at it, and
perhaps revert it - as it seems to be
If the very first thing you have to do with a language feature is make
sure that it doesn't function as designed (which is to execute hostile
content with local privileges), then clearly the design of that
feature is wrong.
Or the default value of the configuration setting has been a bad
Rasmus Lerdorf writes:
How is this any different from
include ../../../../../etc/passwd;
That doesn't let you execute hostile content with local privs.
There are a lot of places where unfiltered user input can cause some
rather severe problems.
I agree! And yet there is plenty
Stefan Esser writes:
I agree with Rasmus. Remote URL Includes are dieing out.
That's not what Rasmus said.
Most released advisories are SQL Injections nowadays and well maybe
Russells next mail says: mysql_query() considered harmful.
When the top Google result for 'php security flaw'
translation the PEAR documentation into Chinese.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
It doesn't hurt anything; in fact, a single big DLL is more resource
efficient than a number of smaller DLLs on win32, as the kernel
doesn't need to spend as much time relocating the DLLs.
--Wez.
On 6/27/05, DvDmanDT [EMAIL PROTECTED] wrote:
Should those really be built into php4ts.dll?
On Tue, 28 Jun 2005, Wez Furlong wrote:
It doesn't hurt anything; in fact, a single big DLL is more resource
efficient than a number of smaller DLLs on win32, as the kernel
doesn't need to spend as much time relocating the DLLs.
Jus twondering... windows has no non-pic thing?
Derick
--
Any thoughts on the idea of a magic method called __main() or
__exec() that would be called if the script being executed is a
class.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
It does things differently; it compiles the DLLs to run at a
particular base address; provided every DLL is compiled at a different
base, then it can be mapped directly into the right memory space. If
there are overlaps between the compiled bases, then the loader can
relocate DLLs until it
At 01:26 AM 6/28/2005, Andrey Hristov wrote:
Should it be named php4ts?
ewww - certainly not. Win32 has no problem with loading two modules,
e.g. php4ts and php5ts, mod_php4 and mod_php5 all in the same process.
But not if the dll names collide.
At 09:56 AM 6/28/2005, Wez Furlong wrote:
If
Sorry - that was a typo. It is already named php5ts.dll.
Michael
Should it be named php4ts?
Andrey
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
PHP Internals - PHP Runtime
Derick,
I did a quick build without the date extension and php5ts.dll dropped
296kb. I did some additional digging. Some of the additional is
because of the new PDO object, and some becuase PCRElib doubled in
size. But the object file that really jumped in size was
zend_execute.obj: from
I opened a bug (http://bugs.php.net/bug.php?id=33459) to report an issue with
the default behavior of class_exists calling __autoload in PHP5. The bug was
marked as bogus, and basically stated that it's PEARs problem. After responding,
the bug can now longer be searched for.
I believe this still
Hi James,
On Tuesday 28 June 2005 23:32, James Crumpton wrote:
function __autoload($name) {
require_once($name);
}
I just don't understand the logic behind throwing a fatal error when I'm
writing code to try and prevent one from occurring.
You should add error checking to your
What do you mean by the script being a class ?
On 6/28/05, Jesse Binam [EMAIL PROTECTED] wrote:
Any thoughts on the idea of a magic method called __main() or
__exec() that would be called if the script being executed is a
class.
--
PHP Internals - PHP Runtime Development Mailing List
To
For example...
--- example.php ---
?php
class Example {
public function __main() {
echo Hello World!;
}
}
?
--- end example.php ---
`php -q example.php` would output Hello World!
With this you could potentially eliminate the global scope if you
chose to. For the record, by no means do I
There is nothing wrong with fopen or include, and PHP isn't
instrinically broken here. The only thing intrinsic about PHP that has
anything to do with these security areas is how PHP is powerfully simple
- lowering the bar for adoption. When you do this, you pick up newbie
programmers who code
rant
This yet again illustrates the sillyness of autoload, if we are going to
have a feature that autoloads classes it should be explicit in it's
usage:
autoload(Class_Name);
defaults to loading Class_Name.php ?
if __autoload exists, it calls that..
adding all sorts of magic to the Class
Can you please send the patch?
If it got stripped, then maybe post a URL.
Thanks.
At 01:49 PM 6/24/2005 -0700, Andrew Prendergast wrote:
Just to add, with the patch one can set PHP_FCGI_MAX_REQUESTS quite high,
which will give a big reqs/sec performance boost, eg:
PHP_FCGI_CHILDREN=10
Al Baker writes:
Turning PHP into a babysitter
Nothing you wrote explains why so many people have had this problem.
Everything you write is an attempt to deny that the problem exists,
deny that serious programmers have the problem, deny that the problem
is due to a badly designed intrinsic, and
Russell Nelson wrote:
Graphical user interface designers understand the idea of an
'affordance'. An affordance is something whose operation is
obvious simply by looking at it. An uparrow button moves
something upwards.
Uh, no. Affordances are the range of possible actions by a user,
Russell Nelson wrote:
Graphical user interface designers understand the idea of an
'affordance'. An affordance is something whose operation is obvious
simply by looking at it. An uparrow button moves something upwards.
'include' is an affordance. It obviously includes a local file.
To me,
Quoted Text:
In other words, it can only be used to include files at or below the
current directory.
This is counter productive, it is a horrible idea to store include
files within (/below) the document root, if you're going to suggest
strange sweeping changes go the reverse direction, ensure
Mike Robinson writes:
Uh, no. Affordances are
Okay, I'm wrong about that. I don't need to push that analogy to make
my point.
You don't save people by filing down the sharp edges on a tool. You
do it by telling them it's sharp.
If you look at a tool, you can tell if it's sharp. If you
On 6/28/05, Russell Nelson [EMAIL PROTECTED] wrote:
If you have to read the man page to find out that 'include' will let
some random user from a third-world country execute 'rm -rf /' on your
server, then I propose that the problem is not that users didn't read
the man page. The problem is
Gareth Ardron writes:
To me, it's obvious that include includes a file - I see no obvious
determination that that file is either local or remote in the include
statement.
Can you name some other languages in which 'include' has such
incredibly sharp edges? C? Python? Perl? BASH? Sed?
Russell Nelson wrote:
Stefan Esser writes:
I agree with Rasmus. Remote URL Includes are dieing out.
That's not what Rasmus said.
Most released advisories are SQL Injections nowadays and well maybe
Russells next mail says: mysql_query() considered harmful.
When the top Google
Russell Nelson wrote:
I think the documentation quite clearly states that /all/ functions that
deal with files may deal with remote files if the fopen wrappers are
enabled
Why did both of my users miss that documentation? The facts seem to
be in opposition to your assertion that the
PHP is not, in my opinion, idiot-proof. You're right on that point.
Where our opinions differ is about what should be done about this.
If a programmer is not capable of controlling an user input, why then
should we trust him with anything ? A lot of other functions taking
user input as arguments
Just for the records, I guess you all know that I meant 'language
construct' where I wrote 'function' instead (in reference to include).
On 6/29/05, Nicolas Bérard Nault [EMAIL PROTECTED] wrote:
PHP is not, in my opinion, idiot-proof. You're right on that point.
Where our opinions differ is
Russell Nelson wrote:
Now, don't tell me that it's not insecure. Everyone here realizes
(and I know this because they've told me) that programmers who are
concerned about security will always check the values passed into
'include'. Why would they need to do that if 'include' wasn't
insecure?
Olivier Hill writes:
Are you suggesting that someone could wipe out your entire machine by
passing a remote script that would system('rm -rf /');?
It would only delete every file owned by the user that the webserver
runs as. On my server, that's 1846 files, some of which I'm fairly
attached
Rasmus Lerdorf writes:
Russell Nelson wrote:
When the top Google result for 'php security flaw' returns
mysql_query() instead of include(), I will agree that you are correct.
I am not sure a Google search is a very good barometer here.
... today it really doesn't seem like it is
35 matches
Mail list logo
