Re: [PHP-DEV] ./buildconf trouble
UNSUBSCRIBE ME PLEASE!! Sebastian Bergmann schrieb: 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]
Re: [PHP-DEV] Bug #12450: Segfaults if recode is loaded after mysql or imap
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: 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. Reading symbols from /usr/lib/libgmp.so.3...done. Reading symbols from /usr/lib/php4/iconv.so...done. Reading symbols from /usr/lib/php4/imlib.so...done. Reading symbols from /usr/lib/libImlib2.so.1...done. Reading symbols from /usr/lib/php4/ldap.so...done. Reading symbols from
Re: [PHP-DEV] Bug #12439 Updated: fopen and URL on the same server
UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
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]
Re: [PHP-DEV] Latest CVS on Linux with Apache 1.3.20
UNSUBSCRIBE ME PLEASE!! Sebastian Bergmann schrieb: 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
UNSUBSCRIBE ME PLEASE!! Andi Gutmans schrieb: 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] Re: thread safety
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: 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] Latest CVS on Linux with Apache 1.3.20
UNSUBSCRIBE ME PLEASE!! Sebastian Bergmann schrieb: 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]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: - 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] Bug #12451: compilation halts on libmysql extension
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: 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
UNSUBSCRIBE ME PLEASE!! Andi Gutmans schrieb: 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]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Ron Chmara schrieb: 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]
Re: [PHP-DEV] Bug #12453: comparing 0==null is true?
UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
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]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Rasmus Lerdorf schrieb:
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]
Re: [PHP-DEV] Object Overloading Interface
UNSUBSCRIBE ME PLEASE!! Sterling Hughes schrieb: g'day, I'm just sending a message to check how different the OO overloading interface will be in the Zend Engine 2? I'm currently writing an extension which uses the current overloading stuff, how different will the new stuff be? will there be some level of backwards compat? basically, what will be the number of man-hours required to migrate? -Sterling -- 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] PHP logfile of PHP variables and scripts
UNSUBSCRIBE ME PLEASE!! Alex Vincent schrieb: One thing I've been thinking about recently is a desire for PHP to provide a function whereby PHP scripts can log incoming variables (such as $HTTP_POST_VARS) and the PHP scripts which process them. Such a function can prove very useful in knowing what a particular user has done. Of course, not every PHP script needs logging in this sense. For instance, if I grab a file from the server and dispatch it to the client via PHP, that likely doesn't need logging. But a PHP script call which includes dropping a MySQL database is another matter... I like the idea of autologging for two reasons. One is to allow me to easily construct a PHP script for replicating my work elsewhere, including creating a database holding the same structure but no information. (This advances the cause of open-source development, in my opinion.) The other is in case someone uses a PHP script on my site maliciously; not only will I be able to track down who did it, but I will likely be able to restore more of what they damaged, entirely. I wrote one possible autologger script. My friend (who is much more experienced in PHP than I am) expanded it somewhat. I'd like to see what the PHP development team thinks of adding an autologger function to the PHP library of functions. Say, logPHPInstance($filename) (which includes a boolean value to disable the autologger function within the log, in case someone tries to execute the log file all over again without editing it.) http://freewarejava.com/ubb/Forum5/HTML/002241.html Opinions? -- 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] Proposal
UNSUBSCRIBE ME PLEASE!!
Heikki Korpela schrieb:
On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
> // 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*");
This sounds brilliant.
Would something glob(3)bish be a bad idea? I could imagine that
1) more people are familiar
with it than with regexs
2) it'd be easier to grasp
in the first place
> -Rasmus
--
-->
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
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 16:28 28/07/2001, Ron Chmara wrote: >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 understand that. This change, if implemented on existing code, requires changes to the vast majority of existing scripts. My guess is that chances are that at least several of these 2,000 files include issues that will be resolved once you move to register_globals=off compatibility. Some of them might be potentially exploited, even though perhaps none of them is. >> 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". Understanding variables is not intuitive to many people either. Telling people "use $foo" or "use $_FORM['foo']" is equally complex in my opinion, since you can copy it, as is, without having to actually understand what variables, or arrays, are. >2. They have almost no examples, whatsoever, to use, for learning how to >work with variables in this manner. This is why I said it should be gradual. Implement the new $_GET/$_POST/$_FORM etc. in 4.0.7, and make the default change in 4.1.0, which would come a month or two later. We can probably get the authors of some of the high profile PHP apps to fix them to be register_globals=off compliant. >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 I don't disagree with you here. I think it's important we set a goal to get into a situation where register_globals is set to off by default. It doesn't have to be tomorrow - after all, we did live with it for many years. The situation is a bit more pressing now that its exploitability is public knowledge, but we can still wait, and do this gradually while trying to educate the userbase about this issue. 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] Proposal
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
It's pretty close to what I had in mind:
At 22:17 28/07/2001, Rasmus Lerdorf wrote:
>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
By definition, it should be somewhat painful, since our working assumption
should be that there are good chances that existing code contains
exploitable bugs related to this issue. No pain no gain :)
> 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.
I mentioned numerous times that I don't think $foo or $_FORM['foo']
are any
different as far as the learning curve is concerned. Newbies
will copy
both as-is without having to actually understand variables and/or
associative arrays.
> 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
That's what I suggested...
> - 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*");
I'm against a global function like this, but in favour of the 2nd flavour,
where you have to explicitly pass a list of variable names to import.
I
also think that it should only support prefix globbing, other types
of
globbing are prone to errors, and also slow to implement.
> - 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.
Looks good.
>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.
I think that neither of these should be done in 4.0.x, as it has a too
far-reaching effect. Nothing stops us from releasing 4.1 on this
very
issue, even if the only difference is just in main.c's INI list and
php.ini-dist.
>For 4.1:
> - I think a namespace approach might be interesting, although
perhaps
> hard to get as granular as import_globals()
Namespaces in this case are nothing but syntactic sugar, so it's not
fundamentally different from $_FORM[var], and not any easier for newbies
to
understand. Also, since we're forking the engine CVS quite soon,
we don't
want to make any serious engine level changes in 4.x
>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
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Phil Driscoll schrieb:
On Sunday 29 July 2001 07:57, Zeev Suraski wrote:
> I'm against a global function like this, but in favour of the 2nd
flavour,
> where you have to explicitly pass a list of variable names to import.
I
> also think that it should only support prefix globbing, other types
of
> globbing are prone to errors, and also slow to implement.
There is an issue that import_globals('GPC') is surely a better option
- if
you are of the opinion that this register globals stuff helps :) -
than
setting register_globals=on since it only applies to the one script
rather
than all scripts, and it may be all that is available as a quick fix
for some
of the scripts out there.
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]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Phil Driscoll schrieb: On Saturday 28 July 2001 20:52, Zeev Suraski wrote: a rebuf to each of my arguments :) Rather than prolong the agony, my point is that in all the cases where a malicious user has the chance to inject a dodgy variable, the code must normally have a logic path which allows the code to pass through an undefined usage of that variable. In testing the code with E_NOTICE on, a warning message will be displayed. The warning message could be beefed up to scare the user a bit more, but for me it is this that hits the nail on the head. I can assure you that the monkeys will screw things up whowever you change the code :) That said, It's easy to live with the proposal, especially with the import_globals() functions. 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]
Re: [PHP-DEV] Bug #12454: Static references are transient inside methods
UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
From:
[EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.6
PHP Bug Type: Variables related
Bug description: Static references are transient inside methods
Another unfortunate bug with references appears to be that statics holding
references inside methods are actually transient, and a reference will
be
lost.
For example, calling the following code several times will initialise
$db
and return every time with a new instance.
function getInstance()
{
static $db;
if (!isset($db)) {
$db = new FS_DB();
}
return $db;
}
whereas the following will give true singeton behaviour and initialise
just
once, as expected.
function getInstance()
{
static $db;
if (!isset($db)) {
$db = new FS_DB();
}
return $db;
}
--
Edit bug report at: http://bugs.php.net/?id=12454edit=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] Bug #12450: Segfaults if recode is loaded after mysqlor imap
UNSUBSCRIBE ME PLEASE!! Heikki Korpela schrieb: On 28 Jul 2001 [EMAIL PROTECTED] wrote: > Recode versions tested: 3.5d, 3.6. > PHP versions tested: 4.0.6. I'd like to add Apache 1.3.19 on OpenBSD-current (i386) with PHP 4.0.6, recode 3.6 and mysql 3.23.40 (non-bundled) to platforms affected. Recode and MySQL work just fine (i.e., they are actually functional, not merely loaded) with mysql first in loaded modules, but crash when recode is loaded first. #0 0x9706374 in ?? () #1 0x40476a16 in ?? () from /usr/local/lib/librecode.so.0.0 #2 0x40478dd0 in ?? () from /usr/local/lib/librecode.so.0.0 #3 0x40479523 in ?? () from /usr/local/lib/librecode.so.0.0 #4 0x403bd6a9 in ?? () from /usr/local/lib/php/20001222/librecode.so #5 0x401d9e94 in ?? () from /usr/lib/apache/modules/libphp4.so #6 0x4018eae0 in ?? () from /usr/lib/apache/modules/libphp4.so #7 0x40163191 in ?? () from /usr/lib/apache/modules/libphp4.so #8 0x4018e8e9 in ?? () from /usr/lib/apache/modules/libphp4.so #9 0x4018b776 in ?? () from /usr/lib/apache/modules/libphp4.so #10 0x401889e2 in ?? () from /usr/lib/apache/modules/libphp4.so #11 0x73aa in ap_init_modules () #12 0x1419c in main () Configure line: ./configure --with-apxs=/usr/sbin/apxs \ --with-config-file-path=/var/www/conf --enable-calendar \ --enable-bcmath --enable-trans-sid --with-yp --with-pcre-regex \ --enable-ftp --with-xml --with-openssl --with-zlib \ --enable-sysvsem --enable-sysvshm --enable-inline-optimization \ --disable-debug --without-curl --without-gdbm --without-gettext --without-imap --without-ldap \ --without-mcrypt --without-mhash --without-mm \ --with-recode=shared --without-snmp --without-gd \ --without-pdflib --disable-dbase --disable-filepro \ --with-mysql=shared,/usr/local --without-pgsql \ --without-iodbc --prefix=/usr/local --sysconfdir=/etc -- --> 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] Bug #12455: Srand and shuffle give odd results
UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
From:
[EMAIL PROTECTED]
Operating system: SunOS 5.8 (Solaris)
PHP version: 4.0.4pl1
PHP Bug Type: *Math Functions
Bug description: Srand and shuffle give odd results
I'm using the following code to create random strings
(passwords):
$password = "";
$array =
array('a','b','c','d','e','f','g','h','i','j','k','l','m','
n','o','p','q','r','s','t','u','v','w','x','y','z',0,1,2,4,
5,6,7,8,9);
srand ((double)microtime()*100);
shuffle($array);
for ($i=0; $i6; $i++) { $password .= $array[$i]; }
Now, for some reason this seems to return only five
different values ever on the Solaris machine I'm running
the code on. And I'm not checking on the same run of the
script, this is based on accessing page with the script
through http and looking at the results for about 150
reloads on two different days.
This is the first time I'm sending a PHP report so I don't
know exactly what information to provide. Please ask for
more if as you see fit.
--
Edit bug report at: http://bugs.php.net/?id=12455edit=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] Re: Proposal
UNSUBSCRIBE ME PLEASE!! "Jeffrey A.Stuart" schrieb: I like this proposal a LOT! See, what I and a few of my friends have recently been doing is starting to teach PHP to website owners. And they have all been taking to it VERY WELL!!! (Actually Rasmus, you may remember this. You were interviewed by TDavid of Scriptschool about 8 months or so ago I think it was. (I'm FurBall FYI. :)) Well, he sat down and did a 16 week course late last year on PHP. It was VERY well recevied by many people!) So more and more non programmers are starting to use PHP. This proposal will allow them to "relativly" painlessly migrate their code to a safer way of coding. On Sat, 28 Jul 2001 22:17:42 -0700 (PDT), [EMAIL PROTECTED] (Rasmus Lerdorf) wrote: [...text of proposal deleted...] -- Jeff Stuart [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] Object Overloading Interface
UNSUBSCRIBE ME PLEASE!! Sterling Hughes schrieb: On Mon, 30 Jul 2001, Stig S. Bakken wrote: > Sterling Hughes wrote: > > > > g'day, > > > > I'm just sending a message to check how different the OO overloading > > interface will be in the Zend Engine 2? I'm currently writing an > > extension which uses the current overloading stuff, how different > > will the new stuff be? will there be some level of backwards > > compat? > > > > basically, what will be the number of man-hours required to migrate? > > I don't think anyone is able to tell you that yet, but expect to have to > rewrite it. It might be a "smaller" change ala the getParameters to > zend_get_parameters_ex one, or it might be a bigger one. > Ahh well, I guess I'll have to commit it before the changes and then expect Zeev and Andi to fix it :) -Sterling > - 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] crontab support for PHP
UNSUBSCRIBE ME PLEASE!! "Stig S. Bakken" schrieb: Max Landborn wrote: > > Hello everyone! > > I'm new to this list, therefore I do not know if you have discussed this > matter before. I'm interested in something like crontab for PHP. This should > be plattform independent and easy to maintain. I have a few ideas of how to > implement it even though I'm rather new to PHP. > > I'm do not have much experience of crontab but I have the need for something > like it on Windows. Also, if you have PHP compiled as a module there is, in > my opinion, no good way of schedule running of scripts. > > What are your thoughts on the matter? Uhm, why not simply run PHP scripts from cron? Or did you want something inside a web server environment? - 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] crontab support for PHP
UNSUBSCRIBE ME PLEASE!! Max Landborn schrieb: > Max Landborn wrote: > > > > Hello everyone! > > > > I'm new to this list, therefore I do not know if you have discussed this > > matter before. I'm interested in something like crontab for PHP. This should > > be plattform independent and easy to maintain. I have a few ideas of how to > > implement it even though I'm rather new to PHP. > > > > I'm do not have much experience of crontab but I have the need for something > > like it on Windows. Also, if you have PHP compiled as a module there is, in > > my opinion, no good way of schedule running of scripts. > > > > What are your thoughts on the matter? > > Uhm, why not simply run PHP scripts from cron? Or did you want > something inside a web server environment? > > - Stig > > -- I am beginning to think that this was not such a good idea that it seemed to me at first. :) Perhaps the subject line should have read "built-in cron in PHP". But if I have PHP compiled as an Apache module (as it is on most web hosting services), I have to set up the cron job to use something like lynx to load a PHP page. I don't think that is a good way of doing it. Also, it works only on Unix. To use the task scheduler on Windows I belive on has to have Administrator privileges and on many Unix hosts you are not allowed to set up your own cron jobs. But making a built-in cron is probably not the right solution. Switching to a better host is. /Max -- 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
UNSUBSCRIBE ME PLEASE!! Alexander Merz schrieb: > > 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. It would not be simpler to avoid the use of font-size? -- 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] PHP logfile of PHP variables and scripts
UNSUBSCRIBE ME PLEASE!! "Stig S. Bakken" schrieb: Alex Vincent wrote: > > One thing I've been thinking about recently is a desire for PHP to > provide a function whereby PHP scripts can log incoming variables (such > as $HTTP_POST_VARS) and the PHP scripts which process them. Such a > function can prove very useful in knowing what a particular user has > done. > > Of course, not every PHP script needs logging in this sense. For > instance, if I grab a file from the server and dispatch it to the client > via PHP, that likely doesn't need logging. But a PHP script call which > includes dropping a MySQL database is another matter... > > I like the idea of autologging for two reasons. One is to allow me to > easily construct a PHP script for replicating my work elsewhere, > including creating a database holding the same structure but no > information. (This advances the cause of open-source development, in my > opinion.) The other is in case someone uses a PHP script on my site > maliciously; not only will I be able to track down who did it, but I > will likely be able to restore more of what they damaged, entirely. > > I wrote one possible autologger script. My friend (who is much more > experienced in PHP than I am) expanded it somewhat. I'd like to see > what the PHP development team thinks of adding an autologger function to > the PHP library of functions. > > Say, logPHPInstance($filename) (which includes a boolean value to > disable the autologger function within the log, in case someone tries to > execute the log file all over again without editing it.) > > http://freewarejava.com/ubb/Forum5/HTML/002241.html > > Opinions? Try posting the idea on [EMAIL PROTECTED] and see if someone catches on to it. If not, I'm afraid you'll have to do it yourself if you want it. :-) - 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] Bug #12456: PHP does not compile with --with-apxs2
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: From: [EMAIL PROTECTED] Operating system: Linux Slackware 8.0 PHP version: 4.0.6 PHP Bug Type: Compile Failure Bug description: PHP does not compile with --with-apxs2 Apache 2.0.16 was configured with --enable-so PHP was configured with --with-mysql=/path/to/mysql --with-apxs2=/path/to/apxs --enable-track-vars --enable-magic-quotes make crashes and gives this output. sapi_apache2.c: In function `php_input_filter': sapi_apache2.c:248: too many arguments to function `ap_get_brigade' sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:443: warning: passing arg 2 of `ap_register_input_filter' from incompatible pointer type -- Edit bug report at: http://bugs.php.net/?id=12456edit=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
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 01:04 29/07/2001, Phil Driscoll wrote: >On Saturday 28 July 2001 20:52, Zeev Suraski wrote: > >a rebuf to each of my arguments :) > >Rather than prolong the agony, my point is that in all the cases where a >malicious user has the chance to inject a dodgy variable, the code must >normally have a logic path which allows the code to pass through an undefined >usage of that variable. In testing the code with E_NOTICE on, a warning >message will be displayed. The warning message could be beefed up to scare >the user a bit more, but for me it is this that hits the nail on the head. *sigh* :) As I said numerous times, PHP gives you standard clean ways to test your variables without generating E_NOTICE's, namely, isset() (very popular) and empty() (less popular, but available all the same). There's a good, fairly darned good chance that exploitable code will generate no warnings whatsoever, and that code that was written with cleanliness in mind will actually be more difficult to debug than sucky E_NOTICE-generating code would. >I can assure you that the monkeys will screw things up whowever you change >the code :) > >That said, It's easy to live with the proposal, especially with the >import_globals() functions. I think the import_globals() is a good idea, provided we do it the right way, and publish it for what it is. I don't think it's going to make a remarkable difference in neither those who would have to migrate (if they want to take the benefit from register_globals=off, they'd still have to go over all of their code) or the newbies (I still believe it's not easier to use $foo than it is to use $_FORM['foo'], definitely if you have to learn about functions (import_globals()) and the notion of the global scope, the 'global' statement and/or $GLOBALS to properly use the $foo version :) I think it'd take a more educated monkey, actually ;) 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] Proposal
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 00:48 29/07/2001, Rasmus Lerdorf wrote:
> > I'm against a global function like this, but in favour of the 2nd
flavour,
> > where you have to explicitly pass a list of variable names to import.
>
>Actually, I mostly had something like: import_globals("ES") in mind
for
>the import all variety. Importing all server and environment
variables
>when there are no external variables imported should not generate
an
>E_NOTICE.
If we go down that route it's ok. I was talking about the
import_globals("P") example, which in my opinion should not work, and
import_globals("P", "*") which should work, but generate an E_NOTICE.
>And jumping to 4.1 for only a config file change seems a bit odd.
It looked odd to me as well, but after thinking about it for a while,
it
looks by far the most right thing to do:
- There are no technical drawbacks whatsoever
- It'll make much more noise than a 4.0.x, and make many more people
realize the difference and do something about it, rather than just
upgrade
and do nothing.
- We finally make use of a x.1 version :)
I think that other than the psychological issue that we're not used
to
bumping the miniversion digit for almost anything, there's no reason
not do
it. If we end up having a semi-major version before 5.0 (which
I doubt,
considering the way things are going now), we can always release 4.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]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 00:27 29/07/2001, Heikki Korpela wrote:
>On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
>
> > // 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*");
>
>This sounds brilliant.
>
>Would something glob(3)bish be a bad idea? I could imagine that
I believe so. I think we should only be using a simple prefix
glob. It's
the simplest one to understand, and the least prone to human errors.
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
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 10:27 29/07/2001, Phil Driscoll wrote: >On Sunday 29 July 2001 17:35, Zeev Suraski wrote: > > *sigh* :) As I said numerous times, PHP gives you standard clean ways to > > test your variables without generating E_NOTICE's, namely, isset() (very > > popular) and empty() (less popular, but available all the same). There's a > > good, fairly darned good chance that exploitable code will generate no > > warnings whatsoever, and that code that was written with cleanliness in > > mind will actually be more difficult to debug than sucky > > E_NOTICE-generating code would. > >We'll have to agree to differ - Over the last year I must have downloaded >about 50 PHP scripts from the popular places with a view to using them. ALL >of them - yes every last one - generated warning messages under E_WARNING. Under E_WARNING or E_NOTICE? Make no mistake, I agree that quite a few and perhaps even probably the majority of the scripts are not E_NOTICE compliant. I just don't agree that the overlap between the group of scripts which are in fact E_NOTICE safe and the group of scripts which are exploitable by this issue is non existent, or even small. 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] CVS Account Request
UNSUBSCRIBE ME PLEASE!! CVS Account Request schrieb: Full name: Serdar Soydemir Email: [EMAIL PROTECTED] ID: tpug Purpose: I am one of the council-members of Turkiye PHP Users Group, www.php.org.tr. We are planning to work on Turkish translation of PHP Manual. If no one/team is assigned on this work, we want to create a new Turkish translation branch on PHP Manual. -- 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] Bug #12455 Updated: Srand and shuffle give odd results
UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
ID: 12455
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Math Functions
Operating System: SunOS 5.8 (Solaris)
PHP Version: 4.0.4pl1
New Comment:
I don't think I understand what the problem is here. I tested
your code with the following:
?
function pwd() {
$password = "";
$array = array('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z',0,1,2,4,5,6,7,8,9);
srand ((double)microtime()*100);
shuffle($array);
for ($i=0; $i6; $i++) { $password .= $array[$i]; }
return $password;
}
$i=0;
while($i500) {
$password = pwd();
$a[$password] = $password;
$i++;
}
echo count($a);
?>
This always returns 500 which means that 500 unique passwords were always
created.
Previous Comments:
[2001-07-29 05:51:30] [EMAIL PROTECTED]
I'm using the following code to create random strings
(passwords):
$password = "";
$array =
array('a','b','c','d','e','f','g','h','i','j','k','l','m','
n','o','p','q','r','s','t','u','v','w','x','y','z',0,1,2,4,
5,6,7,8,9);
srand ((double)microtime()*100);
shuffle($array);
for ($i=0; $i6; $i++) { $password .= $array[$i]; }
Now, for some reason this seems to return only five
different values ever on the Solaris machine I'm running
the code on. And I'm not checking on the same run of the
script, this is based on accessing page with the script
through http and looking at the results for about 150
reloads on two different days.
This is the first time I'm sending a PHP report so I don't
know exactly what information to provide. Please ask for
more if as you see fit.
Edit this bug report at http://bugs.php.net/?id=12455edit=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] Bug #12453: comparing 0==null is true?
UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
Hi btanner!
On Sun, 29 Jul 2001, [EMAIL PROTECTED] wrote:
> 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\"");
try intval("null") to see why
$MyVar isn't converted to string, "null" is converted to int.
-- teodor
--
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 - a bit of my experience
UNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> Think about whether in each of these cases it would have happened
if the
> developers of the app had developed with E_NOTICE on. In a
high number of
> these cases it probably wouldn't. And if this number is close
to 100%,
> then it would point to the fact that there is another less destructive
> solution here.
>
> This is why I want to go through and investigate existing PHP code
and
> have a look.
I'm a user of PHP, who would describe himself as approaching "expert"
in my knowledge.
I took a suggestion from earlier in this thread, and turned off
E_NOTICE. An excellent idea. I found a few holes in some
of my code,
which I was glad to repair, and grateful to the language for pointing
out to me.
The suggestion to turn off register_globals by default is an extremely
bad one. It would make using PHP nothing short of a pain in the ass,
break vast amounts of code, and not improve a whole lot. I _LIKE_
that
I can GET or POST to a page, and the variables will still come from
the
right place.
While considering the security angle, it's important to notice that
there is a tradeoff between a secure system and a functional system,
and that for some people, security just doesn't rate: either the
function (e.g. register_globals) is too valuable, or the downside
of a
security failure is just not all that great. A lot of people
prefer
function over security, and would find it an unwelcome arrogance if
PHP
forced them to twiddle some settings to get it back.
Finally, a small note from my PHP programming experiences:
In order to code with E_ALL, idioms like this:
if ($x)
will produce warnings if $x is not set. If you don't
want the
warnings, you have to replace it with:
if (isset($x)
$x) {
}
"if it's set and it's true"...? ugh.
One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.
if (!$empty)
But as can be seen from the table at
http://bang.dhs.org/~svanegmond/logictest.php
, empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.
This tends to make E_NOTIFY more trouble than it's worth... which is
why people (including the Debian package maintainer) keep it disabled.
Thus I recommend that empty() be fixed to return false for boolean
values. Failing that, that a non-warning-generating logical
equivalent of cast-to-boolean be provided.
--
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 techniques
UNSUBSCRIBE ME PLEASE!! Stephen van Egmond schrieb: I was going to reply to Phil Driscoll's post (from Friday) about E_SECURITY warning level, but thought it might belong better in a different thread. This thread is for collecting some ideas for security enhancements that can happen in PHP, besides the already-known register_globals. My idea: Have PHP reject (fail to process, die, whatever) a hit that is anomalous. Definitions of anomalous: 1. GET variables set while METHOD != GET i.e. form action="foo.php?x=1" method=POST> ... /form> This is a major point of attack identified in the "study in Scarlet". Although I can imagine the above being a programming technique someone, somewhere, has used, future releases might reasonably default to rejecting hits that attempt it. 2. when a uploaded file fails is_uploaded_file(). I felt bad when I saw is_uploaded_file() introduced - it is such a cheezy function call; people shouldn't even have to call it themselves, and I can imagine no situation (except for laziness) that you would not call it. Other ideas? -- ,,, (. .) +--ooO-(_)-Ooo- - -- - - - - | rec.arts.int-fiction archive and research library: | http://bang.dhs.org/if/ -- 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] Bug #12456: PHP does not compile with --with-apxs2
UNSUBSCRIBE ME PLEASE!! Sascha Schumann schrieb: On 29 Jul 2001, [EMAIL PROTECTED] wrote: > From: [EMAIL PROTECTED] > Operating system: Linux Slackware 8.0 > PHP version: 4.0.6 > PHP Bug Type: Compile Failure > Bug description: PHP does not compile with --with-apxs2 > > > Apache 2.0.16 was configured with --enable-so That version is not supported due to API changes in Apache 2.0. IIRC, PHP 4.0.6 is compatible with Apache 2.0.17 and later. The current CVS of PHP 4.0 is known to operate in conjunction with the Apache CVS from a week ago. - Sascha Experience IRCG http://schumann.cx/ http://schumann.cx/ircg -- 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 techniques
UNSUBSCRIBE ME PLEASE!! Chuck Hagenbuch schrieb: Quoting Rasmus Lerdorf [EMAIL PROTECTED]>: > Huh? I use this all the time in my apps. There is absolutely nothing > wrong with having both GET and POST method variables at the same time. > Disallowing this would break almost every app I have ever written. Well, it works fine with Apache, and probably some other servers, but it doesn't work with Netscape Enterprise Server - it's not officially part of the spec, afaik. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED]> Some fallen angels have their good reasons. -- 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 techniques
UNSUBSCRIBE ME PLEASE!! Rasmus Lerdorf schrieb: > Have PHP reject (fail to process, die, whatever) a hit that is > anomalous. Definitions of anomalous: > > 1. GET variables set while METHOD != GET > > i.e. > form action="foo.php?x=1" method=POST> > ... > /form> Huh? I use this all the time in my apps. There is absolutely nothing wrong with having both GET and POST method variables at the same time. Disallowing this would break almost every app I have ever written. > 2. when a uploaded file fails is_uploaded_file(). > > I felt bad when I saw is_uploaded_file() introduced - it is such a > cheezy function call; people shouldn't even have to call it themselves, > and I can imagine no situation (except for laziness) that you would not > call it. In practise people simply call move_uploaded_file() which performs this check. -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]
Re: [PHP-DEV] Security techniques
UNSUBSCRIBE ME PLEASE!! Rasmus Lerdorf schrieb: > > Huh? I use this all the time in my apps. There is absolutely nothing > > wrong with having both GET and POST method variables at the same time. > > Disallowing this would break almost every app I have ever written. > > Well, it works fine with Apache, and probably some other servers, but it > doesn't work with Netscape Enterprise Server - it's not officially part of the > spec, afaik. As long as it works with all browsers, which as far as I can tell it does, then it doesn't really concern me that some servers don't support it. Apache will definitely always support this. -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]
Re: [PHP-DEV] Security techniques
UNSUBSCRIBE ME PLEASE!! Chuck Hagenbuch schrieb: Quoting Rasmus Lerdorf [EMAIL PROTECTED]>: > As long as it works with all browsers, which as far as I can tell it does, > then it doesn't really concern me that some servers don't support it. > Apache will definitely always support this. Yup - I haven't found a browser that has problems with it. And it certainly is useful. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED]> Some fallen angels have their good reasons. -- 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] How is a Syntax Highlight editor made ?
UNSUBSCRIBE ME PLEASE!! "Arcadius A." schrieb: Hello ... It shouldn't be so difficult to make a simple text exitor like Notepad but how to make it have a syntax hightlight ability ? Is there any document dealing with how to make such aditor for PHP or for any other language ? Thanks in advance ...(and sorry if this is not the right place for such a question) Arcad. -- 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] Bug #12457: Mail()
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: From: [EMAIL PROTECTED] Operating system: Widnows 98 PHP version: 4.0.6 PHP Bug Type: PHP options/info functions Bug description: Mail() I want to know , if the function mail() it can be placed in the middle of the page. Without being placed in the beginning, before the HTML> -- Edit bug report at: http://bugs.php.net/?id=12457edit=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] Proposal
UNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> 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
+1
> - We add a new function, somewhat like the current extract()
which looks
> something like this:
> // Another use:
> // Only import the given variables
from Post or Cookie data.
> import_globals("PC",array('user','password','first','last'));
+1
> - 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.
I'm writing "A study in resilience", as a response to the "Study in
Scarlet" newsletter. A bit late, but it can provide a discussion
point.
I'd be happy to see it modified and included in the security chapter.
I like your reasoning for import_globals(). I was wondering if
there
was any thought on my earlier proposal, which would be largely a SAPI
change that:
- dies if GET variable is specified while method != GET
- dies if a file in HTTP_POST_FILES fails is_uploaded_file().
This doesn't solve all the items mentioned in the advisory, but it
squishes quite a few!
-Steve
--
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] CVS Account Request
UNSUBSCRIBE ME PLEASE!! CVS Account Request schrieb: Full name: Halil Sen Email: [EMAIL PROTECTED] ID: halilsen Purpose: Maintaining www.php.net, Developing the PHP runtime -- 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] CVS Account Request schrieb: Full name: Halil Sen Email: [EMAIL PROTECTED] ID: halilsen Purpose: Maintaining www.php.net, Developing the PHP runtime -- 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] Bug #12403 Updated: VARIANT.c : error C2065 'CP_SYMBOL' : undeclared identifier
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: ID: 12403 Updated by: phanto Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: COM related Operating System: NT 4 PHP Version: 4.0.6 New Comment: forgot to close Previous Comments: [2001-07-29 16:16:13] [EMAIL PROTECTED] simply comment them out for now, it doesn't matter. you only won't have these constants defined in your php build (but you can't use them on your machine anyways, they are only accessible on win2k.) i'll add a check. [2001-07-26 10:40:57] [EMAIL PROTECTED] Hello, This is an error message compiling PHP4TS under ms c++ 5 Would you mind help me ? Configuration: php4dllts - Win32 Release_TS Compiling... VARIANT.c E:\php\ext\com\VARIANT.c(100) : error C2065: 'CP_SYMBOL' : undeclared identifier E:\php\ext\com\VARIANT.c(101) : error C2065: 'CP_THREAD_ACP' : undeclared identifier Error executing cl.exe. php.exe - 2 error(s), 0 warning(s) Edit this bug report at http://bugs.php.net/?id=12403edit=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] Bug #12455 Updated: Srand and shuffle give odd results
UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
ID: 12455
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Math Functions
Operating System: SunOS 5.8 (Solaris)
PHP Version: 4.0.4pl1
New Comment:
Well, when I run that code I get 4, not 500. Upping the
number of iterations doesn't help. I think the problem is
with the particular build (extension/OS combination). Any
way to debug this?
Previous Comments:
[2001-07-29 14:26:39] [EMAIL PROTECTED]
I don't think I understand what the problem is here. I tested
your code with the following:
?
function pwd() {
$password = "";
$array = array('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z',0,1,2,4,5,6,7,8,9);
srand ((double)microtime()*100);
shuffle($array);
for ($i=0; $i6; $i++) { $password .= $array[$i]; }
return $password;
}
$i=0;
while($i500) {
$password = pwd();
$a[$password] = $password;
$i++;
}
echo count($a);
?>
This always returns 500 which means that 500 unique passwords were always
created.
[2001-07-29 05:51:30] [EMAIL PROTECTED]
I'm using the following code to create random strings
(passwords):
$password = "";
$array =
array('a','b','c','d','e','f','g','h','i','j','k','l','m','
n','o','p','q','r','s','t','u','v','w','x','y','z',0,1,2,4,
5,6,7,8,9);
srand ((double)microtime()*100);
shuffle($array);
for ($i=0; $i6; $i++) { $password .= $array[$i]; }
Now, for some reason this seems to return only five
different values ever on the Solaris machine I'm running
the code on. And I'm not checking on the same run of the
script, this is based on accessing page with the script
through http and looking at the results for about 150
reloads on two different days.
This is the first time I'm sending a PHP report so I don't
know exactly what information to provide. Please ask for
more if as you see fit.
Edit this bug report at http://bugs.php.net/?id=12455edit=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] Bug #12457 Updated: Mail()
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: ID: 12457 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: PHP options/info functions Operating System: Widnows 98 PHP Version: 4.0.6 New Comment: Yes, you can call it whereever you want. Btw, such questions are best asked at [EMAIL PROTECTED] Previous Comments: [2001-07-29 15:33:13] [EMAIL PROTECTED] I want to know , if the function mail() it can be placed in the middle of the page. Without being placed in the beginning, before the HTML> Edit this bug report at http://bugs.php.net/?id=12457edit=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] php+apache2 anyone?
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: Anyone got an Apache2 running (which one) with PHP (which one) ? thx ciao -- teodor -- 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] JAVA support.
UNSUBSCRIBE ME PLEASE!!
SlowPork schrieb:
Hello.
I instantiated new class [ eg.?
$system = new Java('java.lang.System'); ?> ].
I got blank response, and that child of Apache died.
Is this a bug that I should report?
or I'm missing somthing here? Any expert please give me some
suggestions.
For Apache error log,
[Fri Jul 27 17:40:01 2001] [notice]
child pid 48040 exit signal Bus error (10)
[Fri Jul 27 17:40:02 2001] [notice]
child pid 48041 exit signal Bus error (10)
[Fri Jul 27 17:40:03 2001] [notice]
child pid 48042 exit signal Bus error (10)
I use Apache 1.3.20,PHP
Version 4.0.6
./configure --with-apxs=/usr/local/sbin/apxs
--with-java=/usr/local/linux-jdk1.3.1
phpinfo() shows Java section fine.
java.class.path /usr/local/lib/php/php_java.jar:/usr/local/linux-jdk1.3.1/jre/lib/rt.jar
java.home
/usr/local/linux-jdk1.3.1
java.library
libjava.so
java.library.path /usr/local/lib:/usr/compat/linux/lib:/usr/local/linux-jdk1.3.1/jre/lib/i386:/usr/local/linux-jdk1.3.1/jre/lib/i386/hotspot:/usr/local/linux-jdk1.3.1/jre/lib/i386/native_threads
From, php.ini
java.home=/usr/local/linux-jdk1.3.1
java.class.path=/usr/local/lib/php/php_java.jar:/usr/local/linux-jdk1.3.1/jre/lib/rt.jar
extension_dir=/usr/local/lib/php/20001222
extension=libphp_java.so
java.library.path=/usr/local/lib:/usr/compat/linux/lib:/usr/local/linux-jdk1.3.1/jre/lib/i386:/usr/local/linux-jdk1.3.1/jre/lib/i386/hotspot:/usr/local/linux-jdk1.3.1/jre/lib/i386/native_threads
java.library=libjava.so
I tried both Sun Java 1.3.1, and Blackdown
1.2.2. It gave same error on Apache. Java itself works fine
from shell.
I use FreeBSD 4.3 Stable, Linux
compat mode is on
# kldstat
Id Refs Address
Size Name
1 3 0xc010
38c5f4 kernel
2 1 0xc0d47000
3000 daemon_saver.ko (screen saver)
3 1 0xc0d4c000
12000 linux.ko
I also set LD_LIBRARY_PATH before I
start Apache.
# setenv LD_LIBRARY_PATH /usr/local/lib:/usr/compat/linux/lib:/usr/local/linux-jdk1.3.1/jre/lib/i386:/usr/local/linux-jdk1.3.1/jre/lib/i386/hotspot:/usr/local/linux-jdk1.3.1/jre/lib/i386/native_threads
I run 'ld' . Seems it finds most
dynamic links.
# ld /usr/local/linux-jdk1.3.1/jre/lib/i386/libjava.so
/usr/libexec/elf/ld: warning: cannot
find entry symbol _start; not setting start address
Thank you.
slowpork at hotmail.com
Re: [PHP-DEV] Security techniques
UNSUBSCRIBE ME PLEASE!!vUNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Zeev Suraski ([EMAIL PROTECTED]) wrote:
> At 12:04 29/07/2001, Stephen van Egmond wrote:
> >2. when a uploaded file fails is_uploaded_file().
>
> My English parser bailed out on this one :)
How's your PHP parser doing? :)
foreach $f ($HTTP_POST_FILES) {
if (!is_uploaded_file($f))
{
die "Ayiee!";
}
}
> While it may be rare to find a situation in which it's useful more
than
> move_uploaded_file(), these cases do exist. I'm not sure what's
wrong with
> it, can you be more specific?
My feelings upon seeing it were of the "aw, man, couldn't something
else check for that?". There isn't any reason you would want
to accept
a file that failed is_uploaded_file() -- so why bother even leaving
it
as a possibility.
While I'm typing this, I also understand that it may have been an
emergency introduction into the language in response to a vulnerability
report. And I also understand that functionality that exists
in some
Server API should, in some way, be reproducible in the core without
duplicating code.
-Steve
--
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 - a bit of my experience
UNSUBSCRIBE ME PLEASE!! Stephen van Egmond schrieb: Zeev Suraski ([EMAIL PROTECTED]) wrote: > - register_globals=on leads to insecure code, which was demonstrated time > and time again in the past. > - Once it's off, we're going to provide methods of accessing variables > which are just as easy, and quite easier in case you access them from > functions. Having form variables register as global variables is not the > 11th commandment, and it's kind of odd to see people treat it as such. It is quite the handy feature, and it will be a bummer to see it go. > - E_NOTICE is a runtime issue, one which you would have to check under all > possible paths in your logic. That's why leaving security stuff to runtime > is always never a good idea. Setting register_globals to off gives you > development-time security. I must point out that if we're referring to existing code bases, E_NOTICE and register_globals=off require as much work: all code paths have to be exercised to catch all the old-style idioms. I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. Although this would improve things, it bears noting that: - it deprecates a valid (on Apache) idiom which, at least, Rasmus uses - this only makes it harder to spoof variables, not impossible. But at least that's something. Whatever. The idea hasn't caught on. I recognize it probably wasn't worthy. -Steve -- 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] Bug #12461: browser hangs unless I uncheck keep alives in IIS5.0
UNSUBSCRIBE ME PLEASE!! [EMAIL PROTECTED] schrieb: From: [EMAIL PROTECTED] Operating system: win2k PHP version: 4.0.6 PHP Bug Type: Any Bug description: browser hangs unless I uncheck keep alives in IIS5.0 Upgraded from PHP4.04pl to PHP4.06 and now the browsers are hanging. I am writing an application with php and mysql on win2k and IIS5.0 Browser seemed to load the whole page, but the loading bar on the bottom never stopped or would time out. After I turned off keep alives on IIS it is back to normal and quick. I tried backdating mysql and php and nothing seemed to work. The server may be too quick but I will now research keep alives. any ideas anyone.. -- Edit bug report at: http://bugs.php.net/?id=12461edit=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 - a bit of my experience
UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 21:34 29/07/2001, Stephen van Egmond wrote: >Zeev Suraski ([EMAIL PROTECTED]) wrote: > > - register_globals=on leads to insecure code, which was demonstrated time > > and time again in the past. > > - Once it's off, we're going to provide methods of accessing variables > > which are just as easy, and quite easier in case you access them from > > functions. Having form variables register as global variables is not the > > 11th commandment, and it's kind of odd to see people treat it as such. > >It is quite the handy feature, and it will be a bummer to see it go. It's not going. It's just being turned off by default and flagged as "use only if you REALLY know what you're doing" feature, and don't really care about portability (the only way to write portable PHP apps is to assume register_globals is off, that's been true for a while now). > > - E_NOTICE is a runtime issue, one which you would have to check under all > > possible paths in your logic. That's why leaving security stuff to > runtime > > is always never a good idea. Setting register_globals to off gives you > > development-time security. > >I must point out that if we're referring to existing code bases, >E_NOTICE and register_globals=off require as much work: all code paths >have to be exercised to catch all the old-style idioms. I disagree. For E_NOTICE=off, you have to go through all of the possible logical paths. For register_globals=off, you only have to know your input variables, and a searchreplace would do. It's true that in some apps, where you have no idea or don't remember what the input variables are, it would take some time to figure out what the input vars are, but it's still much easier than going through all of the possible logical paths. >I was trying to step back a bit and identify some of the patterns in >the attacks identified in the paper. One extremely popular pattern was >spoofing variables by overwriting them: GET variables overwriting >POST, usually, and I suggested that some SAPI stunt be pulled to catch >that. > >Although this would improve things, it bears noting that: > >- it deprecates a valid (on Apache) idiom which, at least, Rasmus uses >- this only makes it harder to spoof variables, not impossible. > But at least that's something. > >Whatever. The idea hasn't caught on. I recognize it probably wasn't >worthy. Protecting POST vars from GET has no serious security viability, even though as I said a few days ago, in practice, a hell of a lot more people know how to spoof GET vars than those who know how to spoof POST or cookie vars. I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give you the best of all worlds, as it would really lead you to use the right variable for the job. 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] Bug #12432 Updated: not valid mysql ressource
UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE
ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME
PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!
[EMAIL PROTECTED] schrieb:
ID: 12432
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: MySQL related
Operating System: GNU Linux
PHP Version: 4.0.6
New Comment:
The eMail system is not working correctly,
there is some more sourcecode in my message,
please watch it directly
http://www.php.net/bugs.php?id=12432
First I thought it is some sort of scope problem,
but it is also reproducable with different var Names.
I think he ignores the link variable totally. Maybe
closes the default link (first created)
Previous Comments:
[2001-07-27 20:43:22] [EMAIL PROTECTED]
This is currently a feature. Although you haven't given full source
I assume both 'mysql_connect()'s were the same. Two or more connects with
the same parameter reuse the allready established connection and don't
create a new one. So, closing one of them closes all other, too.
Re-Open if my assumption were wrong.
[2001-07-27 13:31:35] [EMAIL PROTECTED]
$eLink = mysql_connect(...);
.
.
.
class test {
function einTest() {
$eLink = mysql_connect();
mysql_close($eLink);
}
}
$aVar = new test();
$aVar->einTest();
mysql_query("...",$eLink);
-> not valid mysql ressource
After einTest() it looks like it closes the outside mysql_connection
($eLink) no matter how the connection
var in einTest() is named!
Serious stuff!
Edit this bug report at http://bugs.php.net/?id=12432edit=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]
