[PHP-DEV] Bug #12445: ./configure suxx
From: [EMAIL PROTECTED] Operating system: Linux 2.2.19 PHP version: 4.0.6 PHP Bug Type: Compile Failure Bug description: ./configure suxx ./configure [...] --with-zlib [...] does not work. i have zlib 1.1.3 installed in /usr/local/zlib but it always says zlib =1.0.9 required i think this is a general configuration script bug, so please fix it. got no problems with 4.0.4p1 ... -- Edit bug report at: http://bugs.php.net/?id=12445edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12446: php4isapi.dll path
From: [EMAIL PROTECTED] Operating system: pws98 PHP version: 4.0.6 PHP Bug Type: PWS related Bug description: php4isapi.dll path win98/pws4/php4.0.6, using php4isapi.dll. The oringinal path for php4isapi was h:\php. I change the path to e:\php by using RegEdit. But actual path is still the old h:\php. I know this by phpinfo(), and if I delete h:\php\php4isapi.dll, the php server will not work. -- Edit bug report at: http://bugs.php.net/?id=12446edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Commits
Please hold your commits until further notice. A pretty huge mega patch is coming, and since it touches pretty much all of PHP, I need a 'relaxed' repository... Thanks -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12447: Function to encode strings for XML
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4.0.6
PHP Bug Type: Feature/Change Request
Bug description: Function to encode strings for XML
Currently I use
function xml_encode($xml) {
$xml = str_replace(array('ü', 'Ü', 'ö',
'Ö', 'ä', 'Ä',
'ß'
),
array('#252;', '#220;', '#246;',
'#214;', '#228;', '#196;',
'#223;'
),
$xml
);
$xml = preg_replace(array(/\([a-z\d\#]+)\;/i,
/\/,
/\#\|\|([a-z\d\#]+)\|\|\#/i,
/([^a-zA-Z\d\s;\.\:\=\\-\/\%\?\!\'\(\)\[\]\{\}\$\#\+\,\@_])/e
),
array(#||\\1||#,
amp;,
\\1;,
'#'.ord('\\1').';'
),
$xml
);
return $xml;
}
to 'encode' strings for use with XML. A 'PHP Land' implementation of this
would be handy, I think.
--
Edit bug report at: http://bugs.php.net/?id=12447edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
I wrote a thorough response while being disconnected, but it's kind of pointless to send it considering the face to face discussion we had today. The only thing I'd like say here is that in my opinion, the fact form variables are defined as globals (as opposed to being defined just as automatically inside $_GET/$_POST or $_FORM) is hardly what makes PHP what it is. Auto form variable registration is very important and is one of the cornerstones of PHP, but it'd be equally good if it had a different syntax. Other cornerstones that make PHP what it is are the clean and non obscure syntax (I bet Thies doesn't use PHP for his shell scripts because of auto form variable registration...), the easy to use database APIs which come within the binary, and the fact it contains a full set of Web tools built into it. I think that portraying PHP as some weak version of Perl with auto global form variables is not even an understatement, but just plain wrong... Anyway, to be more constructive - Andi had an idea when we were catching a cab earlier today (yesterday). His idea (which I'm just pitching, we haven't thought this through at all yet) is that instead of having register_globals on, or off, we would have it as unset, by default. When unset (i.e., on new installations) - PHP will not run, but instead display information about register_globals, its security implications, examples, and a general recommendation to turn it off if at all possible. We can easily point the user to the location of the php.ini file that he has to edit in order to modify register_globals to be either on or off. Again, I'm just pitching this idea, I'm not entirely sure if it's good or not. Personally, I still lean towards having register_globals off by default for new installations. This will have a very small effect on existing apps (for better and worse), it'd encourage (force) application developers to write portable applications (which is a good thing - apps based on register_globals=on are not portable, since many security-aware people turn it off), and obviously, solve the security issues we've been discussing. If we release it as 4.1.0, it's going to generate enough noise to make people aware of this issue, which is also a good thing. Zeev At 10:30 27/07/2001, Rasmus Lerdorf wrote: This is an important step, that as I said, I wanted to make for years. I just argue that as protective as you are over register_globals=on, the real flaw is there, and this is the place it should be fixed. Fixing the fact that E_NOTICE is on may also be viable, but in practice: - A huge number of cases where E_NOTICE's will be generated isn't related to security in any way, and people will be kind of pissed by it, and probably turn it back off That's an issue that can be addressed. We perhaps need better granularity on the E_NOTICE. If we distribute a php.ini-recommended, we can, and probably should enable E_NOTICE's by default. It's not the solution to the problem raised in the advisory. The very first and primary example in the advisory would most definitely have been caught by an E_NOTICE, so I don't see how this doesn't address the advisory. For reference the first example in the advisory is: ?php if ($pass = hello) $auth = 1; ... if ($auth == 1) echo some important information; ? First, the guy who wrote the advisory didn't check his code, because the above could never actually be a problem since he confuses == and = and actually always sets $auth=1, but ignoring that and fixing his code, if you turn on E_NOTICE this script generates: Warning: Undefined variable: pass in foo.php on line 2 Warning: Undefined variable: auth in foo.php on line 5 And the second example is: ?php if (!($fd = fopen($filename, r)) echo(Could not open file: $filenameBR\n); ? Again, an obvious bracket mismatch so this example also doesn't run, but running this with E_NOTICE gives: Warning: Undefined variable: filename in foo.php on line 2 Warning: Undefined variable: filename in foo.php on line 3 Same goes for example 3 which is: ?php include($libdir . /languages.php); ? Then he talks about the file upload issues which is a separate problem and one we have addressed. And then he talks about .inc files and suggests that people who just use .php for include files are vulnerable because their scripts could be run out of context. This is a different issue as well. But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway. And one language less that these people are able to use. That's an empty statement, Rasmus... The auto-registered form variables are not any less usable if we change the access method to
RE: [PHP-DEV] Security Issues
At 12:36 27/07/2001, Brian Tanner wrote: Differently - sometimes Dangerously - Never I think that this means that this is quite serious, and mind-bogglingly common security flaw. When your app behaves differently, there's a one out of two, or one out of five, or one out of ten chance that this can be exploited for bad purposes. Most security exploits originate in an application which behaves in a way that the author did not anticipate. In your case, you're either lucky, talented, or both. My view is that if your apps can behave differently, chances are that there's a huge number of other apps which can also be manipulated to behave differently, and quite a few of them can be manipulated into doing 'dangerous' things. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
Yes, a $_FORM variable container is also on my TODO list for the new track_vars implementation... At 14:00 27/07/2001, Brian Tanner wrote: Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something That gets populated based on the ordering set for GPC right now in the .ini file? I think it would go really far towards helping a newbie (and to helping people fix their existing code), if there was one place that they could look, to find the old value that they are now missing. People can still go to _Get, _Post, and _Cookie if they require that level of granularity, but I think most will be happy with a general container for what Register_Globals *would* have done. -Brian T -Original Message- If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand just how did this variable get its value?. Having the $_GET[ post_user_name] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Sat, 28 Jul 2001, Zeev Suraski wrote:
Anyway, to be more constructive - Andi had an idea when we were catching a
cab earlier today (yesterday). His idea (which I'm just pitching, we
haven't thought this through at all yet) is that instead of having
register_globals on, or off, we would have it as unset, by default. When
unset (i.e., on new installations) - PHP will not run, but instead display
information about register_globals, its security implications, examples,
and a general recommendation to turn it off if at all possible.
I think one issue here is that people are so used to using certain
kind of language syntax that they're simply overestimating the effort
of typing $_{GET,POST}['foo'] when needed. With some time to
get used to it, I think most of the people will see why this is a good
idea. Your idea sounds like something that might help with this.
One thing that would further this cause would be to explain how to
start converting your existing codebase to be more secure in
small chunks.
I have no experience with other web servers than Apache, but with
Apache I use for my own homepages a .htaccess similar to the one
below. I have similar settings for many virtual hosts and directories
in the server configuration files.
# Security
php_flag register_globals Off
# Error tracking / displaying / logging
php_value error_reporting 2047
php_flag display_errors Off
php_flag log_errors On
php_value error_log 'REPLACE_ME'
php_flag track_errors On
Zeev
--
--
Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 05:08 27/07/2001, [EMAIL PROTECTED] wrote:
Addressed to: Rasmus Lerdorf [EMAIL PROTECTED]
[EMAIL PROTECTED]
Or you can simply stop these people from using PHP which is another
effect turning off register_globals will have.
Java does not have this problem because Java is so complex that this
same set of users can not program in Java. Fixing this problem by
making PHP more complex and eliminating these problem users is a bad
idea as far as I am concerned.
YES!!
NO!! :) Saying people would stop using PHP (or won't get started) because
of this change is a gross exaggeration. IMHO, the one and only issue at
hand here is downwards compatibility, and not usability or ease of use, not
even a bit.
As I see it the whole issue revolves around the fact that some people
get used to the fact that undefined variables have a value, and rely on
it. These are the people who get hit when a hacker slips in his own
value in on such variables. If the programmer had just initialized
the variable at the top of the program, there would not be a problem.
I think the best thing you could do about this issue is:
1. ALWAYS report the use of an uninitialized variable, no matter what
level of error checking is in effect. At the very least send a message
to the error_log for every undefined variable. If the error level allows
it also complain to the browser and send an email to ServerAdmin. That
won't break any existing scripts, but depending on the text of the
email, it could give system administrators incentive to correct problem
scripts. [1] The 'send email' default should be on in the distribution.
That's not going to find half, or a quarter, or whatever of the problems,
since PHP has tools to cleanly handle undefined variables - namely isset()
and empty(). They, or at least isset(), are quite popular.
2. Make it a FATAL error. Too bad that would break so many scripts...
Maybe it could be a major effect of the E_SECURE bit. On the other
hand, if you are serious about stamping out the uninitialized variable
problem, this will do it.
I'd argue that that's actually going to make an equally messy effect on the
PHP developer community, with a much lower gain, and also, a considerable loss.
There's *nothing* wrong with the following code:
function foo()
{
for ($i=0; $i10; $i++) {
$str .= $i;
}
return $str;
}
It's safe, it's quick, and it uses an uninitialized variable. There are a
hell of a lot more cases where using uninitialized variables is entirely
secure, than cases where it's not. As a 'purist' coming from C background,
I'd always initialize variables. PHP users would not.
BTW, I'm just being argumentative here. I personally think that having
E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A
great deal of PHP programmers will not agree with me, though, so I haven't
made up my mind on whether I support changing this default or not.
Another main difference between having E_NOTICE turned on and having
register_globals=off is that with register_globals being off, your app will
not work, fair and square, unless you modify it to read its arguments from
the right track vars arrays. As for just setting E_NOTICE - it won't help
unless people actually check all the possible control paths of their
logic. Of course, they should do it in the testing phase. And yes, I'm
willing to bet that a great deal of them does not.
Register Globals is very convienent for people who write code with
PHP. Turning it off would be a great loss. The problem is not that
values passed to the server appear as variables, it is that some
programmers don't make sure they initialize every variable before they
use it.
There are two problems:
1. Programmers are humans, and humans are creatures that tend to make
mistakes, including stupid ones, and worse, repeat them over and over again
2. PHP, with register_globals=on, mixes information coming from the user
with information coming from code written by the developer, to a degree
where it's impossible to differentiate between the two. Given problem #1,
this often leads to security problems.
In a perfect world, you'd be able to address #1 and then #2 would have been
a non issue. But we're walking the Earth, and not wonderland, so I think
we should concentrate on solving #2 :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12448: Disturbing memory corruption/crash
From: [EMAIL PROTECTED] Operating system: Linux 2 2.16 PHP version: 4.0.6 PHP Bug Type: Reproducible crash Bug description: Disturbing memory corruption/crash I've been attemping to track down a case of memory corruption that showed itself with 'new ClassName' returning null or 'gettype()' on the result returning a garbage string. I'm using php as a module with apache, and with the zend optimiser, although the effect is the same with or without the optimiser enabled. Apart from other bugs in 4.0.6 that I've reported, up until now things have been fine with some largish runs of up to a few 1000 lines of code. Whilst this is reproduceable 100% with my application, unfortunately I can't contribute a smaller program yet to demonstrate this despite various attempts, but I'll try some more on this as there's not a lot to go on otherwise. Perhaps someone can do a purify run with a solaris build? The effect of getting a null result from new or garbage from gettype() first showed when new'ing a trivial class before one that amongst other things used shared memory and semaphores via the put_var/get_var routine family. Something that has aparantly been working well and flawlessly so far. It was the result of newing the complex class that was corrupted. Curiously, moving the trivial (empty) class construction after the more complex one 'cured' the problem. The complex constructor was calling a function returning array data by reference that came from calling a function that returned array data by value. This had been obtained via shm_get_var. Another change that made the problem disappear was to return the data either by value or by reference in *both* cases, although performance analysis showed this to be slower in both cases. The presumed crash (the browser lost its connection to the server) occured when I called the function twice that ultimately returned the data from shared memory. Again this didn't happen when returning consistently by value or reference. Of course the workarounds don't mean that the problem wasn't still happening, but perhaps that what is probably corruption didn't have an impact at that point. So the problem may be related to the use of the sem and shm routines, returning 300 element associative arrays of integer to strings by a mixture or reference/value or something else. It may also be in the code outside of php of course. Sorry that I can't give more to go on but there is most definitely a problem lurking somewhere. Please feel free to email me with any things that I might try to get a further handle on the problem with my own application in the (currently likely) event that I can't reproduce with a simpler application. For library versions, ldd on httpd gives the following: libpam.so.0 = /lib/libpam.so.0 (0x40019000) libdl.so.2 = /lib/libdl.so.2 (0x40021000) libz.so.1 = /usr/lib/libz.so.1 (0x40025000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40034000) libresolv.so.2 = /lib/libresolv.so.2 (0x40061000) libm.so.6 = /lib/libm.so.6 (0x4007) libnsl.so.1 = /lib/libnsl.so.1 (0x4008e000) libgdbm.so.2 = /usr/lib/libgdbm.so.2 (0x400a5000) libc.so.6 = /lib/libc.so.6 (0x400ac000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) Cheers, Nick -- Edit bug report at: http://bugs.php.net/?id=12448edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Zeev Suraski wrote: Anyway, to be more constructive - Andi had an idea when we were catching a cab earlier today (yesterday). His idea (which I'm just pitching, we haven't thought this through at all yet) is that instead of having register_globals on, or off, we would have it as unset, by default. When unset (i.e., on new installations) - PHP will not run, but instead display information about register_globals, its security implications, examples, and a general recommendation to turn it off if at all possible. We can easily point the user to the location of the php.ini file that he has to edit in order to modify register_globals to be either on or off. i was thinking about having an additional error_level E_SECURITY besides E_NOTICE and having both of them activated by default in future php.ini distributions although i like your idea too, i'm afraid it won't reach all users as often they are not the ones who do the installation but just use it so chances are that the system administrator responsible for installing php just turns register_global off again after installation while the warnings produced will never reach the developers E_SECURITY, on the other hand, would have effect at runtime, not on installation, and the message would reach the developers (if they care at all, i have seen enough code having @s in all places or beginning with error_reporting(0) :( ) besides that E_SECURITY could be used in other places as well ... the only drawback on my solution right now is that E_SECURITY together with display_errors would breack every script generating HTTP headers, as globals registration is done way before the script is started so i thought of an additional mechanism that would not register GPCs generally as globals but on demand, producing warnings whenever the feature is really used instead of when it is generaly turned on like ?php echo $a[hello]; ? produces Warning: Use of undefined constant hello - assumed 'hello' ... or ?php echo $hello; ? leads to Warning: Undefined variable: hello we could register globals on demand while issueing Warning: Undefined variable: hello - assumed $HTTP_GET_VARS['hello'] ok, this might lead to a slight performance hit with register_globals on, but i wouldn't as it is identified as bad practice anyway as long as it doesn't break existing code but just slows it down [...] it'd encourage (force) application developers to write portable applications (which is a good thing - apps based on register_globals=on are not portable, [...] hm, maybe having E_PROTABILITY as an additional error_reporting level would be worth a thought ... ? PS: i definetly like the idea of having track_vars generate a FORM array of some sort containint both GET and POST vars, being able to change from methods without having to double-check the form processing code could be worth it regarding the convenience of having _GET[] besides HTTP_GET_VARS[] and such i'm not sure yet (and i hope i got it right that both variants will be just references to the same array internally ?) maybe having another ini-parameter like short_track_vars or convenience_track_vars? as i said, i'm not at all sure about it yet ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Apologies in advance to Zeev for arguing on this one, but be assured I firmly
believe that your solution would be to the detriment of PHP and a better
solution is possible :)
On Saturday 28 July 2001 12:44, Zeev Suraski wrote:
NO!! :) Saying people would stop using PHP (or won't get started) because
of this change is a gross exaggeration. IMHO, the one and only issue at
hand here is downwards compatibility, and not usability or ease of use, not
even a bit.
Sorry Zeev - the answer is YES. I and no doubt thousands of others will turn
register_globals on because it gives much more readable code, much less
typing and does not IMHO add one jot to the security of my applications.
That's not going to find half, or a quarter, or whatever of the problems,
since PHP has tools to cleanly handle undefined variables - namely isset()
and empty(). They, or at least isset(), are quite popular.
I always use something like:
if(!isset($Thing) /*and possibly some range checking*/))
$Thing=sensible default;
In no way is
if(!isset(_GET['Thing']) /*and possibly some range checking*/))
{
$Thing=sensible default;
}
else
{
$Thing=(_GET['Thing']);
}
any more secure (nor would it be if I wrote sensible default back to _GET.
Anyway, to check my sanity i have reread the security advisory which I first
read on the day it was published, and I am even more conviced now that
register globals=off has the tiniest of effects for gpc variables wheras
E_NOTICE has a massive effect.
Here are the examples from the advisory:
--
?php
if ($pass === hello) //= corrected to ===
$auth = 1;
...
if ($auth == 1)
echo some important information;
?
replace $pass with _GET['pass'] and the code is
equally insecure. Turn E_NOTICE on and the novice programmer will get a
warning message for the unset $pass.
--
?php
if (!($fd = fopen($filename, r))
echo(Could not open file: $filenameBR\n);
?
replace $filename with _GET['filename'] and this lunatic piece of code
remains a lunatic piece of code. If $filename is not meant to be coming from
the outside world then with E_NOTICE on there would be a warning message for
the unset filename.
--
?php
include($libdir . /languages.php);
?
Ok, with register_globals=off then $libdir could not be directly overwritten
from outside (unless there was some code which made that happen) however
E_NOTICE would generate a warning for an unset $libdir
--
File upload.
If you don't use the new functions you are potentially stuffed with register
globals on or off.
As an aside - we could have a php.ini directive which could 'break' code
which did not use the new functions - if we save an uploaded file with one
name, but set the $userfile_name to something else, and only rename the
original to $userfile_name after a call to is_uploaded_file or
move_uploaded_file.
--
?php
if (file_exists($theme)) // Checks the file exists on the local system (no
remote files)
include($theme);
?
This seems to be the same as the fopen($filename... example above.
--
In libdir/loadlanguage.php:
?php
...
include($langDir/$userLang);
?
include files called out of context. The solution is to configure your web
server, or put the include files outside the webroot so that they cannot be
run out of context.
In this example, typically $langdir should have been set inside the
application or a configuration file, but $userLang will typically have come
from the user either with this request, or previously and stored in a
database in the users profile.
So under the register_globals = off scheme, we would often end up with
something along the lines of:
?php
...
include($langDir/_GET['userLang']);
?
where $langDir is unset. We can all see how secure that is :)
--
Session files.
I am happy to concede that there should be a php.imi directive which stops
variables which can more or less be trusted, such as env and session from
entering the global namespace, so that if you want to read them you have to
look in the correct place.
--
In conclusion I would urge those who want to set register_globals=off to
reconsider. A better solution is required. The better solution involves some,
all, or more of:
E_WARNING
more granularity to the register_globals directive
the file upload changes I mentioned as an aside
Cheers
--
Phil Driscoll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] thread safety
Zeev If the thread safety stuff you've just committed might fiz the ISAPI problems, and you want some testing doing, please shout out. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12425 Updated: apache core dumps when started with a php.ini in /usr/local/lib
ID: 12425 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Apache related Operating System: Linux - Red Hat 7.1 PHP Version: 4.0.6 New Comment: The Config Command Line (Per Request by Sniper): ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl=/usr/local/ssl/ --enable-magic-quotes --disable-short-tags --enable-dmalloc --with-zlib --enable-bcmath --with-bz2 --enable-calendar --enable-ctype --with-curl --with-dom=/usr/local --enable-exif --with-fdftk=/usr/local --enable-ftp --with-gd --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-freetype-dir=/usr/local --with-ttf --with-t1lib --with-gettext --with-imap=/usr/local --with-ircg --enable-mbstring --with-mcrypt --with-mhash --with-mysql --with-pdflib=/usr/local --with-tiff-dir=/usr/local --with-pgsql --with-pspell --with-qtdom --with-readline --with-mm --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvsem --enable-sysvshm --enable-yp --enable-inline-optimization This configuration works perfectly as a static apache module just the DSO breaks. Previous Comments: [2001-07-27 23:37:41] [EMAIL PROTECTED] What was the configure line used to configure PHP? [2001-07-27 09:56:33] [EMAIL PROTECTED] Just Compile 4.0.6 (Apache-1.3.20 DSO) amazingly all the stuff I compiled in worked. When I have a php.ini in /usr/local/lib and try to start the server it bombs out (the back trace is below). The cgi version seems to work accordingly and report all modules working correctly (via php_info()). The apache config file seems correct aswell. Any help would be greatly appreciated. This is on a stock Red Hat 7.1 system. (gdb) bt #0 0x405b4d63 in virtual_file_ex (state=0xbfffd5b8, path=0xbfffc580 /usr/local/lib/php.ini, verify_path=0) at tsrm_virtual_cwd.c:335 #1 0x404bf6e0 in expand_filepath ( filepath=0xbfffe690 /usr/local/lib/php.ini, real_path=0x0) at fopen_wrappers.c:531 #2 0x404bedcf in php_fopen_and_set_opened_path ( path=0xbfffe690 /usr/local/lib/php.ini, mode=0x406a7ec8 r, opened_path=0x40738364) at fopen_wrappers.c:237 #3 0x404bf44e in php_fopen_with_path (filename=0x406a7eca php.ini, mode=0x406a7ec8 r, path=0x8120e8c .:/usr/local/lib, opened_path=0x40738364) at fopen_wrappers.c:414 #4 0x404bfbd8 in php_init_config (php_ini_path_override=0x0) at php_ini.c:240 #5 0x404bd93f in php_module_startup (sf=0x40737260) at main.c:827 #6 0x404bb1e8 in php_apache_startup (sapi_module=0x40737260) at mod_php4.c:259 #7 0x404bbcd6 in php_init_handler (s=0x80f1890, p=0x80f1868) at mod_php4.c:744 #8 0x08083dda in ap_init_modules () at eval.c:41 #9 0x0808e340 in main () at eval.c:41 #10 0x4019c177 in __libc_start_main (main=0x808df9c main, argc=1, ubp_av=0xb8ec, init=0x8053268 _init, fini=0x80c6300 _fini, rtld_fini=0x4000e184 _dl_fini, stack_end=0xb8dc) at ../sysdeps/generic/libc-start.c:129 Edit this bug report at http://bugs.php.net/?id=12425edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12449: I've tried inserting my php.ini file in five locations and it won't load it
From: [EMAIL PROTECTED] Operating system: Windows 98 SE PHP version: 4.0.6 PHP Bug Type: GD related Bug description: I've tried inserting my php.ini file in five locations and it won't load it I've put then extention modules in a directory on my C Partition named php_mod, I've saved the php.ini file into the C:\, C:\PHP4, C:\WINBLOWS, C:\WINBLOWS\SYSTEM, C:\WINNT It still will not load my configuration over the default built into the php4ts.dll, here is a copy of my php.ini file [PHP] ; $Id: php.ini-dist,v 1.78.2.2 2001/06/01 03:20:49 sniper Exp $ ;;; ; About this file ; ;;; ; This file controls many aspects of PHP's behavior. In order for PHP to ; read it, it must be named 'php.ini'. PHP looks for it in the current ; working directory, in the path designated by the environment variable ; PHPRC, and in the path that was defined in compile time (in that order). ; Under Windows, the compile-time path is the Windows directory. The ; path in which the php.ini file is looked for can be overriden using ; the -c argument in command line mode. ; ; The syntax of the file is extremely simple. Whitespace and Lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL ~E_NOTICE), or a quoted string (foo). ; ; Expressions in the INI file are limited to bitwise operators and parentheses: ; |bitwise OR ; bitwise AND ; ~bitwise NOT ; !boolean NOT ; ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; ; foo = ; sets foo to an empty string ; foo = none; sets foo to an empty string ; foo = none ; sets foo to the string 'none' ; ; If you use constants in your value, and these constants belong to a ; dynamically loaded extension (either a PHP extension or a Zend extension), ; you may only use these constants *after* the line that loads the extension. ; ; All the values in the php.ini-dist file correspond to the builtin ; defaults (that is, if no php.ini is used, or if you delete these lines, ; the builtin defaults will be identical). ; Language Options ; ; Enable the PHP scripting language engine under Apache. engine = On ; Allow the ? tag. Otherwise, only ?php and script tags are recognized. short_open_tag = On ; Allow ASP-style % % tags. asp_tags = Off ; The number of significant digits displayed in floating point numbers. precision= 14 ; Enforce year 2000 compliance (will cause problems with non-compliant browsers) y2k_compliance = Off ; Output buffering allows you to send header lines (including cookies) even ; after you send body content, at the price of slowing PHP's output layer a ; bit. You can enable output buffering during runtime by calling the output ; buffering functions. You can also enable output buffering for all files by ; setting this directive to On. output_buffering = Off ; You can redirect all of the output of your scripts to a function. For ; example, if you set output_handler to ob_gzhandler, output will be ; transparently compressed for browsers that support gzip or deflate encoding. ; Setting an output handler automatically turns on output buffering. output_handler = ; Transparent output compression using the zlib library ; Valid values for this option are 'off', 'on', or a specific buffer size ; to be used for compression (default is 4KB) zlib.output_compression = Off ; Implicit flush tells PHP to tell the output layer to flush itself ; automatically after every output block. This is equivalent to calling the ; PHP function flush() after each and every call to print() or echo() and each ; and every HTML block. Turning this option on has serious performance ; implications and is generally recommended for debugging purposes only. implicit_flush = Off ; Whether to enable the ability to force arguments to be passed by reference ; at function call time. This method is deprecated and is likely to be ; unsupported in future versions of PHP/Zend. The encouraged method of ; specifying which arguments should be passed by reference is in the function ; declaration. You're encouraged to try and turn this option Off and make ; sure your scripts work properly with it in order to
[PHP-DEV] Bug #12449 Updated: I've tried inserting my php.ini file in five locations and it won't load it
ID: 12449 Updated by: lyric Reported By: [EMAIL PROTECTED] Old Status: Open Status: Analyzed Bug Type: GD related Operating System: Windows 98 SE PHP Version: 4.0.6 New Comment: Look in the first section of the output from phpinfo(), and there's a line like: Configuration File (php.ini) Path : /usr/local/lib/php.ini Obviously yours will say something else, but that's where it's getting the .ini file from. Previous Comments: [2001-07-28 11:26:46] [EMAIL PROTECTED] I've put then extention modules in a directory on my C Partition named php_mod, I've saved the php.ini file into the C:\, C:\PHP4, C:\WINBLOWS, C:\WINBLOWS\SYSTEM, C:\WINNT It still will not load my configuration over the default built into the php4ts.dll, here is a copy of my php.ini file [PHP] ; $Id: php.ini-dist,v 1.78.2.2 2001/06/01 03:20:49 sniper Exp $ ;;; ; About this file ; ;;; ; This file controls many aspects of PHP's behavior. In order for PHP to ; read it, it must be named 'php.ini'. PHP looks for it in the current ; working directory, in the path designated by the environment variable ; PHPRC, and in the path that was defined in compile time (in that order). ; Under Windows, the compile-time path is the Windows directory. The ; path in which the php.ini file is looked for can be overriden using ; the -c argument in command line mode. ; ; The syntax of the file is extremely simple. Whitespace and Lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL ~E_NOTICE), or a quoted string (foo). ; ; Expressions in the INI file are limited to bitwise operators and parentheses: ; |bitwise OR ; bitwise AND ; ~bitwise NOT ; !boolean NOT ; ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; ; foo = ; sets foo to an empty string ; foo = none; sets foo to an empty string ; foo = none ; sets foo to the string 'none' ; ; If you use constants in your value, and these constants belong to a ; dynamically loaded extension (either a PHP extension or a Zend extension), ; you may only use these constants *after* the line that loads the extension. ; ; All the values in the php.ini-dist file correspond to the builtin ; defaults (that is, if no php.ini is used, or if you delete these lines, ; the builtin defaults will be identical). ; Language Options ; ; Enable the PHP scripting language engine under Apache. engine = On ; Allow the ? tag. Otherwise, only ?php and script tags are recognized. short_open_tag = On ; Allow ASP-style % % tags. asp_tags = Off ; The number of significant digits displayed in floating point numbers. precision= 14 ; Enforce year 2000 compliance (will cause problems with non-compliant browsers) y2k_compliance = Off ; Output buffering allows you to send header lines (including cookies) even ; after you send body content, at the price of slowing PHP's output layer a ; bit. You can enable output buffering during runtime by calling the output ; buffering functions. You can also enable output buffering for all files by ; setting this directive to On. output_buffering = Off ; You can redirect all of the output of your scripts to a function. For ; example, if you set output_handler to ob_gzhandler, output will be ; transparently compressed for browsers that support gzip or deflate encoding. ; Setting an output handler automatically turns on output buffering. output_handler = ; Transparent output compression using the zlib library ; Valid values for this option are 'off', 'on', or a specific buffer size ; to be used for compression (default is 4KB) zlib.output_compression = Off ; Implicit flush tells PHP to tell the output layer to flush itself ; automatically after every output block. This is equivalent to calling the ; PHP function flush() after each and every call to print() or echo() and each ; and every HTML block. Turning this option on has serious performance ; implications and is generally recommended for debugging purposes only. implicit_flush = Off ; Whether to enable the ability to force arguments to be passed by reference ; at function call
[PHP-DEV] Re: Bug #12241 Updated: imap.so: undefined symbol: mxdriver in Unknown on line 0
On Thu, 19 Jul 2001 03:01:03 +0200, jmmele [EMAIL PROTECTED] wrote: all the modules I compile are working but imap.so I have found the same problem with PHP 4.0.6 - on two different Red Hat Linux generations. I know about all the tricks regarding --with-imap-ssl and --with-imap-kerberos, but none of them helped. Neither did changing imap version. Now, I have found a hack which seems to work, for some strange reason: Don't use --with-imap Instead, after the rest of PHP has compiled, go to the php source-dir and do: gcc -fPIC -shared -DCOMPILE_DL_IMAP -DHAVE_IMAP \ -I. -I./TSRM -I./main -I`/usr/include/apache -I./Zend \ -I/usr/include/imap -I./ext/imap \ `grep ^CPPFLAGS Zend/Makefile | cut -f2- -d=` -DHAVE_IMAP2000 \ -DHAVE_IMAP_SSL ext/imap/php_imap.c -o modules/imap.so \ -L.libs /usr/lib/c-client.a -lssl -lcrypto -lc (Notice the _back_-ticks around the grep-expression.) Note that there are no references to Kerberos. That's because I use a version of imap-devel which doesn't have Kerberos bloat: http://rpms.arvin.dk/imap-no_kerberos/ PS: This php-imap problem did not exist in previous PHP versions. -- Greetings from Troels Arvin, Copenhagen, Denmark -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 3.0 Bug Summary Report
PHP 3.0 Bug Database summary - http://bugs.php.net Num Status Summary (543 total including feature requests) ===[*General Issues]== 4180 Open is_link returns false when target doesnt exist (should return true) 9610 Bogus Dead link 9820 Open File upload with any input tag 10101 Bogus apache + mysqld + php3 == libphp3.so incorrect symbol... 10457 Bogus ALKHOBAR ===[*Install and Config]== 7386 Feedback referenced symbol not found when starting Apache ===[Compile Failure]== 1145 Open Ypu cannot compile with --with-ldap using the Solaris7 bundled ldap-libs/header 1298 Open need to use -taso with Netscape LDAP libs 1461 Open won't compile with Stronghold 2.2 or 2.3 1933 Open Unable to compile PHP3 with Oracle8 support 1997 Open Compilation Problems 2225 Open Compile error in ldap.c 2282 Open Compile failure with Stronghold 2.4.1 2490 Open Perl regular expression functions not available in windows binary 2585 Open Error linking Oracle 7.3.2 libraries on SCO OpenServer 5.0.4 2658 Open error while compiling PHP as apache module 2729 Open Fatal error: Unable to open ??? in - on line 0 2751 Open Storage size of buf isn't known 2823 Open undefined symbol: SQLParamData 2824 Open Inconsistent parameter list declaration for... 2903 Open fails to compile ifx.ec, report a syntax-error 3033 Open Fatal compile error on functions/ldap.c 3185 Open Undefined symbol 3217 Open ld error when compiling as Apache DSO and --with-mysql 3218 Open Can't compile php_ftp.dll 3426 Open make with iodbc failed and I've found the problem 3501 Open Compiling errors with Oracle-Funktions 3528 Open Can't compile php 3.0.14 with Oracle support 3677 Open files not found 3766 Open configure doesn't allow for the Oracle N32 client SDK to be used 3776 Open functions/db.c:107: parse error before '*' 4028 Open wrong directories included for oracle 8.1.6 4217 Open IBM DB2 will not compile. 4233 Open The Interbase module won't compile. 4266 Open Undeclared variables in function/imap.c starting ar line 435 4392 Open Compile failure with GD 1.7, possibly others 4412 Open xml failure 4417 Open Informix specific parse error in functions/ifx.ec 4544 Open Incompatiblility with latest (3.0) version of PDFlib 4899 Open PHP Core Dumps With Apache 1.3.12 7734 Open missing php3_ifx.h ===[Compile Warning]== 3151 Open php.exe compile warnings because of arpa/inet.h 6942 Open php sockets unusable with irix-OS ===[dBase related] 3091 Open dbase_replace_record miscounts number of fields 3429 Open Warning: Unable to open database... 4802 Open php.exe crashes while trying to execute the get_record function ===[DBM/DBA related]== 2890 Open DBM extension on win32 does not valid database identifier error 3371 Open dbmfetch reurns an empty string 3423 Open dbmopen() not thread-safe 3809 Duplicate DBM extension for Win32 PHP3 is malfunctioning and/or has a flaw 3862 Open dbmReplace dbmDelete return inverse value 6720 Open persistent Warning: driver initialization failed on db_open db2 2.7.7 ===[Documentation problem] 11155 Open ===[Dynamic loading related]== 1188 Open Configuration not work 1586 Open In the compiled Win32 package, the php3_ldap doesn't load. 1993 Open Startup failure of liphp3.so 2027 Open Can't dynamicly load any extension dll file 2250 Open nt-service problem 2414 Open php3_vmailmgr.so refuses to load 2862 Open LDAP in Win32 Bin dist is linked to MSVCRTD.DLL 3168 Open cannot start apache 1.3.9 if mysql is compiled in, but can RESTART successfully 3292 Open MySQL module causes DSO to fail. 3321 Open Apache Complaining about undefined symbol: dlst_first 3659 Open mod_php + apache w/mod_so hangs in sched_yield 3680 Open Apache won't start after install php3 3752 Open Apache configtest dumps core with DSO versioning 3781 Open Cannot load /libexec/libphp3.so 3861 Open php as a dyn. mod. configured with IBM db2 support prevents svr startup 9565 Open php3_ldap.dll is compiled as DEBUG ===[Feature/Change Request]=== 2393 Open Can't use parse_url for url validation ===[IMAP related]= 2816 Open Imap_open error
Re: [PHP-DEV] Security Issues
On Sat, 28 Jul 2001, Zeev Suraski wrote: BTW, I'm just being argumentative here. I personally think that having E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A great deal of PHP programmers will not agree with me, though, so I haven't made up my mind on whether I support changing this default or not. Consider it this way: If an user decides to use my library that is E_NOTICE clean and doesn't have E_NOTICE, what happens? If I decide to use a library that isn't E_NOTICE clean and I have E_NOTICE, what happens? The main issue here from my point of view is interoperation and distribution of software. 2. PHP, with register_globals=on, mixes information coming from the user with information coming from code written by the developer, to a degree where it's impossible to differentiate between the two. Given problem #1, this often leads to security problems. As long as we have a small quantity of small programs and libraries with minor distribution, the maintainance effort of obfuscated code is not vast, and thus flexibility may be default, and perhaps the primary aim. As software written in PHP grows in popularity and the codebase itself grows in size, maintainance becomes harder. Thus I think that a clear message from the developers - whether it's E_NOTICE or register_globals or an open letter called Code Together - that states we are concerned that it's becoming increasingly hard to incorporate large codebases together without compromising stability and security is in my opinion in place. But that's of course only me. Zeev -- -- Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] ./buildconf trouble
I recently updated autoconf to version 2.52 and now I get this with running ./buildconf rebuilding main/php_config.h.in ./aclocal.m4:929: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:472: PHP_SUBST is expanded from... ./aclocal.m4:929: the top level autoconf: tracing failed -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ./buildconf trouble
Sebastian Bergmann wrote: I recently updated autoconf to version 2.52 and now I get this with running ./buildconf Never mind, Sascha just told me to stick to 2.13. -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12450: Segfaults if recode is loaded after mysql or imap
From: [EMAIL PROTECTED] Operating system: Red Hat Linux 6.2 PHP version: 4.0.6 PHP Bug Type: Recode related Bug description: Segfaults if recode is loaded after mysql or imap PHP segfaults if recode.so (php's recode extension as a shared library) is loaded _after_ the imap or mysql extensions. Re-ordering the php.ini file so that the extension=recode.so line is the first extension=...-line stops the segfaults. Recode versions tested: 3.5d, 3.6. PHP versions tested: 4.0.6. config.nice: #! /bin/sh # # Created by configure ./configure \ --prefix=/usr \ --libdir=/usr/lib/php4 \ --includedir=/usr/include \ --datadir=/usr/share/php \ --with-config-file-path=/etc \ --enable-discard-path \ --enable-inline-optimization \ --enable-magic-quotes \ --enable-track-vars \ --enable-memory-limit \ --enable-wddx \ --enable-bcmath \ --enable-sigchild \ --with-xml \ --with-mm \ --with-openssl \ --enable-ftp=shared \ --enable-exif=shared \ --with-gd=shared,/usr \ --with-ttf \ --enable-gd-imgstrttf \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --enable-sysvsem=shared \ --enable-sysvshm=shared \ --enable-shmop=shared \ --with-unixODBC=shared \ --with-mysql=shared,/usr \ --with-ldap=shared \ --with-pgsql=shared \ --with-gettext=shared \ --with-pspell=shared \ --with-snmp=shared \ --enable-ucd-snmp-hack \ --with-sybase-ct=shared,/usr \ --with-pdflib=shared \ --with-oci8=shared \ --with-swf=shared,/home/troels/rpm/BUILD/php-4.0.6/swflib \ --enable-sockets=shared \ --with-gmp=shared \ --with-dom=shared \ --with-qtdom=shared,/usr/lib/qt-2.3.0 \ --with-iconv=shared \ --with-curl=shared \ --enable-apc=shared \ --with-ming=shared \ --with-imlib=shared \ --with-recode=shared \ --with-zlib=/usr \ $@ php.ini: extension_dir = /usr/lib/php4 ;; Global PHP defaults warn_plus_overloading = On ; warn if the + operator is used with strings track_errors= On ; Store the last error/warning message in $php_errormsg (boolean) track_vars = On ; enable the $HTTP_*_VARS[] arrays, where * is one of magic_quotes_gpc= On ; magic quotes for incoming GET/POST/Cookie data ; many people think that the system is a pain in the ; a**, but it probably does represent a security ; feature for in-experienced PHP developers. Turn it ; off if you don't want PHP to mess with your incoming ; variables. include_path= .:/usr/share/php/PEAR:/usr/share/php/imlib session.save_path = /var/state/php extension=php_apc.so extension=domxml.so extension=exif.so extension=ftp.so extension=gd-with_gif.so extension=gettext.so extension=gmp.so extension=iconv.so extension=imlib.so extension=ldap.so extension=pdf.so extension=pgsql.so extension=pspell.so extension=sablot.so extension=snmp.so extension=sockets.so extension=swf.so extension=sybase_ct.so extension=sysvshm.so extension=sysvsem.so extension=shmop.so extension=odbc.so extension=curl.so extension=mysql.so extension=recode.so Back-trace: === GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /usr/lib/libssl.so.0...done. Reading symbols from /usr/lib/libcrypto.so.0...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /usr/lib/php4/php_apc.so...done. Reading symbols from /usr/lib/php4/domxml.so...done. Reading symbols from /usr/lib/libxml2.so.2...done. Reading symbols from /usr/lib/php4/exif.so...done. Reading symbols from /usr/lib/php4/ftp.so...done. Reading symbols from /usr/lib/php4/gd-with_gif.so...done. Reading symbols from /usr/lib/libttf.so.2...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/libjpeg.so.62...done. Reading symbols from /usr/gd-with_gif/lib/libgd.so.1.8...done. Reading symbols from /usr/lib/php4/gettext.so...done. Reading symbols from /usr/lib/php4/gmp.so...done.
[PHP-DEV] Bug #12439 Updated: fopen and URL on the same server
ID: 12439 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Filesystem function related Operating System: Linux-2.2.19 PHP Version: 4.0.6 New Comment: I found the problem. My DNS was broken. Previous Comments: [2001-07-27 20:06:14] [EMAIL PROTECTED] Hi, I got a following problem with this script: ? $tempurl = http://www.hostinsameserver.com;; $tempurl2 = http://www.yahoo.com/;; $tempfile2 = fopen($tempurl2/index.html, r); echo $tempfile2; $tempfile = fopen($tempurl/index.html, r); echo $tempfile; ? The first one is hosted in the same machine as the script that is running on it ( it can even be the same site ). The second is hosted outside the network. When it tries to access the first URL it hangs forever. No CPU consumption or memory. I tried with PHP-3.0.18 ( same machine ) and it works, so I discarded DNS problems. Any hint ? Renato. Edit this bug report at http://bugs.php.net/?id=12439edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Latest CVS on Linux with Apache 1.3.20
Cannot load /usr/local/apache/libexec/libphp4.so into server: undefined symbol: TSRMLS_FETCH ./configure --enable-inline-optimization --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-pgsql --with-zlib=/usr --without-pear -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest CVS on Linux with Apache 1.3.20
Did you update TSRM Zend? Andi At 09:21 PM 7/28/2001 +0200, Sebastian Bergmann wrote: Cannot load /usr/local/apache/libexec/libphp4.so into server: undefined symbol: TSRMLS_FETCH ./configure --enable-inline-optimization --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-pgsql --with-zlib=/usr --without-pear -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest CVS on Linux with Apache 1.3.20
Andi Gutmans wrote: Did you update TSRM Zend? Yes, of course. And I did a clean build, too. You're Andi, right? Not Zeev in disguise? :-) -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: thread safety
As a matter of fact it doesn't, on its own, fix too much. It makes the thread safe code much faster and a bit more centralized, which should help improve the thread safety code to stability. There are more improvements coming on this front soon :) At 06:07 28/07/2001, Phil Driscoll wrote: Zeev If the thread safety stuff you've just committed might fiz the ISAPI problems, and you want some testing doing, please shout out. Cheers -- Phil Driscoll -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
- My mind is pretty firm about implementing shortcuts for $HTTP_*_VARS. People are going to rebel big time if we remove their global variables by default, and make them use these exceptionally long alternatives instead. Most people I talked to (virtually all of them except for you :) agreed with that - E_SECURITY is a good idea, but like the other ideas raised in this discussion, it doesn't have all that much to do with the specific issue at hand. We have no magical way of detecting usage of variables which is a potential security risk, as opposed to one which is not. Unfortunately, both are very common. At 05:45 28/07/2001, Hartmut Holzgraefe wrote: Zeev Suraski wrote: Anyway, to be more constructive - Andi had an idea when we were catching a cab earlier today (yesterday). His idea (which I'm just pitching, we haven't thought this through at all yet) is that instead of having register_globals on, or off, we would have it as unset, by default. When unset (i.e., on new installations) - PHP will not run, but instead display information about register_globals, its security implications, examples, and a general recommendation to turn it off if at all possible. We can easily point the user to the location of the php.ini file that he has to edit in order to modify register_globals to be either on or off. i was thinking about having an additional error_level E_SECURITY besides E_NOTICE and having both of them activated by default in future php.ini distributions although i like your idea too, i'm afraid it won't reach all users as often they are not the ones who do the installation but just use it so chances are that the system administrator responsible for installing php just turns register_global off again after installation while the warnings produced will never reach the developers E_SECURITY, on the other hand, would have effect at runtime, not on installation, and the message would reach the developers (if they care at all, i have seen enough code having @s in all places or beginning with error_reporting(0) :( ) besides that E_SECURITY could be used in other places as well ... the only drawback on my solution right now is that E_SECURITY together with display_errors would breack every script generating HTTP headers, as globals registration is done way before the script is started so i thought of an additional mechanism that would not register GPCs generally as globals but on demand, producing warnings whenever the feature is really used instead of when it is generaly turned on like ?php echo $a[hello]; ? produces Warning: Use of undefined constant hello - assumed 'hello' ... or ?php echo $hello; ? leads to Warning: Undefined variable: hello we could register globals on demand while issueing Warning: Undefined variable: hello - assumed $HTTP_GET_VARS['hello'] ok, this might lead to a slight performance hit with register_globals on, but i wouldn't as it is identified as bad practice anyway as long as it doesn't break existing code but just slows it down [...] it'd encourage (force) application developers to write portable applications (which is a good thing - apps based on register_globals=on are not portable, [...] hm, maybe having E_PROTABILITY as an additional error_reporting level would be worth a thought ... ? PS: i definetly like the idea of having track_vars generate a FORM array of some sort containint both GET and POST vars, being able to change from methods without having to double-check the form processing code could be worth it regarding the convenience of having _GET[] besides HTTP_GET_VARS[] and such i'm not sure yet (and i hope i got it right that both variants will be just references to the same array internally ?) maybe having another ini-parameter like short_track_vars or convenience_track_vars? as i said, i'm not at all sure about it yet ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Hey, I thought of an idea yesterday which could make everyone happy. In the default php.ini we set the register_globals to a new value unset. If PHP runs with this INI value it will display a page telling you that you need to define the register_globals option in your php.ini and explains the pros/cons security concerns involved (IMO we should recommend register_globals=off). This way we won't break existing sites which already have php.ini and we have an easy way to feed new users w/ the required information. Of course, I still think we should think of a nicer way to access form variables such as $_FORM[] in order to make it easier for the developer. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12451: compilation halts on libmysql extension
From: [EMAIL PROTECTED] Operating system: Linux 2.4.7 PHP version: 4.0.6 PHP Bug Type: Compile Failure Bug description: compilation halts on libmysql extension make[1]: Entering directory `/usr/local/src/php-4.0.6/ext/mysql/libmysql' /bin/sh /usr/local/src/php-4.0.6/libtool --silent --mode=compile gcc -I. -I/usr/local/src/php-4.0.6/ext/mysql/libmysql -I/usr/local/src/php-4.0.6/main -I/usr/local/src/php-4.0.6 -I/usr/local/apache/include -I/usr/local/src/php-4.0.6/Zend -I/usr/local/ssl/include -I/opt/interbase//include -I/usr/local/src/php-4.0.6/ext/mysql/libmysql -I/usr/local/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.6/TSRM -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c libmysql.c In file included from libmysql.c:9: global.h:240: warning: redefinition of `uint' /usr/include/sys/types.h:146: warning: `uint' previously declared here global.h:241: warning: redefinition of `ushort' /usr/include/sys/types.h:145: warning: `ushort' previously declared here In file included from libmysql.c:12: m_string.h:180: parse error before `__extension__' m_string.h:180: parse error before `' make[1]: *** [libmysql.lo] Error 1 make[1]: Leaving directory `/usr/local/src/php-4.0.6/ext/mysql/libmysql' make: *** [all-recursive] Error 1 my configure line is the following: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --with-zlib --enable-ftp --with-interbase=/opt/interbase/ i am running a freshly installed slackware 8.0 with apache 1.3.20 glibc is 2.2.3 I Noticed that there is a compilation define -DLinux=22 shouldn't it be 2.4? -- Edit bug report at: http://bugs.php.net/?id=12451edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Björn Schotte wrote: * Rasmus Lerdorf wrote: significantly more secure PHP scripts out there. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. We could at least educate people about extract(). :-P - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora installed
Anil Madhavapeddy wrote: Alexander Merz wrote: Please, could you use relative specifications (font-size: small) instead of absolute (font-size: 11px) in the css? It's more user-friendly and i don't have to look for my eyeglasses each time. Unfortunately, this isn't consistent cross-platform. http://www.alistapart.com/stories/fear4/4.html (thx Jim Winstead for the above link) I'm completely open to better solutions, but haven't actually be able to find any. We _could_ start browser sniffing I guess. My experience is that you have to make fonts slightly bigger for Netscape 4.x on X11 and Opera. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: At 06:01 28/07/2001, Phil Driscoll wrote: I and no doubt thousands of others will turn register_globals on because it gives much more readable code, much less typing and does not IMHO add one jot to the security of my applications. I have no doubt that thousands would turn it back on. I can't do anything about it, and as I said numerous times in numerous metaphors, I'm quite alright with that. I have roughly 2,000 files to fix before I can use it with my biggest client :-) I also can't imagine people avoiding PHP because variables are accessed using $_FORM['foo'], instead of $foo. People are not *THAT* dumb or lazy. Discussing this issue in the OSCon, Rasmus claimed that right now he can teach PHP to a monkey in 3 hours, and he wouldn't want to be limited only to smart Gorillas in the future. I firmly believe that if a monkey can figure out $foo, $_FORM['foo'] is not going to be the showstopper. Well, there's two *new* learning curves for the never-programmed-before user (monkey?). 1. Understanding arrays. The newest of the newbies are still trying to grok strings, and concepts like get or post. 2. They have almost no examples, whatsoever, to use, for learning how to work with variables in this manner. Both of these issues, combined, increase the monkey factor. Most online and printed tutorials available do not use HTTP_*_VARS (or any future TBI vars shorthand). The example code, all over php.net and zend.com, does not use it. Even if we encourage them to consider it the right thing to do, they don't really know how to go about doing it. I went to google.com, and typed in PHP tutorials,and started looking around... http://hotwired.lycos.com/webmonkey/99/21/index2a.html - Explains HTTP_POST_VARS, but doesn't use it. http://www.devshed.com/Server_Side/PHP/ - Many tutorials, looked at a few, none used it. http://www.linuxguruz.org/z.php - Many tutorials, looked at a few, none used it. http://www.phpdeveloper.org/ - Many tutorials, looked at a few, none used it. I think, perhaps, that this is one of the reasons that so much of the PHP codebase isn't usable with register_globals = off. The learning curve is steep, because it's basically undocumented, in terms of tutorials, examples, downloadable snippets/functions, etc. So we have a chicken/egg problem, where the new monkey has to make a big jump, and use a relatively hidden method of acccessing variables, because almost every tutorial on PHP is wrong. Even the smart gorillas, (the ones writing the tutorials), aren't using it, probably because they never learned how/why to use it.. If we can fix #2, #1 may not require as much effort. As it currently stands, if would be akin to releasing a version of PHP where we suddenly required them (by default, disable if needed) to change every variable they used from $foo to %[foo]. So, beyond my normal ramble: If we were to do this, we might want to start by putting examples in place, if only to show users _how_ to do it. Even if we don't, we still need to start populating examples, if only to show users how they _can_ work with register globals= off. -Ronabop --2D426F70|759328624|00101101011001100111 [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/ The opinions expressed in this email are not necessarily those of myself, my employers, or any of the other little voices in my head. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12452: Parsing error in eval function
From: [EMAIL PROTECTED] Operating system: Linux 2.4.3 (Mandrake) PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: Parsing error in eval function Using a buffer variable to collect HTML output as the script progresses, at the end of the script using eval to output (and parse) the buffer. However, first line of ouput is as follows: ?xml version=1.0 encoding=UTF-8? This causes a parse error; I would guess this is because PHP is not strict on the text that follows ?, hence the fact that it is xml does not register and it gives (as expected) a parse error. Surely this should not cause a parse error. A similar script to the part I use is included below: ?php $page_output=?xml . ?htmlhead./html; eval(?$page_output); ? -- Edit bug report at: http://bugs.php.net/?id=12452edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12453: comparing 0==null is true?
From: [EMAIL PROTECTED] Operating system: Win2k PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: comparing 0==null is true? If you compare the integer(0) to the string null, PHP thinks they are the same. Am I hopped up on goofballs, or whats up here? $MyVar=0; if($MyVar==null) print(apparently $MyVar is equal to \null\); else print(its not null, its $MyValue); -- Edit bug report at: http://bugs.php.net/?id=12453edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Proposal
The best thing about PHP is that it has such a shallow learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course oversimplifying things quite a bit, but it is the root
of the issue here.
The question is not whether we should do something about this, the
question is what we should do about it. After reading all these messages
and talking to people about it in person, here is what I see we need to
achieve (not necessarily in order of importance):
1. A painless migration path for existing code
2. Minimal impact on the learning curve. I really don't like requiring
neophyte users to have to understand associative arrays before they
can get started with PHP.
3. Maximum protection for existing and new PHP apps
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
- We add a new function, somewhat like the current extract() which looks
something like this:
// Import all Get/Post/Cookie variables in to the global(/current?)
// namespace. Function could also be called import_symbols() or
// register_globals() although the latter would be a bit confusing
// since it doesn't take a boolean arg like the ini version.
// If register_globals is on already this would be a no-op
import_globals(GPC);
// Another use:
// Only import the given variables from Post or Cookie data.
import_globals(PC,array('user','password','first','last'));
// And perhaps some globbing:
// Import any variable with abc in its name from anywhere.
// Could alternatively use SQL-style or perhaps real regex
// expressions here although I think full regex support would be
// slightly overkill and perhaps too confusing for people.
import_globals(GPCES,*abc*);
- With the release of 4.0.7 we start hyping this security issue by
linking to a spruced up version of the security chapter in the manual
which describes how exactly to use these new tools.
We could also provide a user-space implementation of the _$GET,
$_POST... population logic and a user-space implementation of
import_globals() so existing applications could check the PHP version
and include our forward-compliance.inc file in order for their apps
that conform to the new style to be backward compatible with older
PHP installations. Or better, our .inc/.php file would do a version
check for them.
- We also start hyping that people who write and distribute PHP apps
should strive to make their code E_NOTICE-clean.
For 4.0.8:
- If we didn't mess up in 4.0.7 and actually got something that works for
people we consider turning on E_NOTICE by default and/or turning
register_globals off by default.
For 4.1:
- I think a namespace approach might be interesting, although perhaps
hard to get as granular as import_globals()
Reasoning behind something like import_globals():
Large existing web apps reference these GPECS variables everywhere. There
may literally be thousands of lines of code to change and perhaps 10's of
thousands of lines of code to check. Simply turning off register_globals
would make these scripts fail invisibly. The end result will be that
people just turn register_globals back on which may even be the documented
requirement for these distributed apps. This doesn't help anybody.
However, if the authors of these apps could make their code somewhat more
secure by simply adding:
import_globals(P);
to their app-wide include file and assuming they only want POST variables
imported, then they would probably do that. It isn't much of a security
benefit at this level, but if they took it slightly further and checked
their forms for form elements and pulled out the valid ones and specified
these in an array we suddenly have a whole lot more security and instead
of changing thousands of lines, they have added perhaps 5 or 6.
And from a neophyte user perspective they don't need to understand
associative arrays, they simply need to understand
import_globals(GPC,form_*) which is much easier to teach. (assuming
they named their form elements form_foo, form_bar, ...)
Obviously the import_globals documentation should point people at the
_GET[] direct access approach as well, although an import_globals() call
with a precise list of valid variables should be even safer.
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
