At 08:48 26/07/2001, Rasmus Lerdorf wrote:
Just replace your if ($ok) with if (!empty($ok)), and you have a perfect
exploitable code that produces no warnings.
But in this case someone has gone to the trouble to figure out what
empty() does. And generally they use empty() on things that
At 08:32 7/27/2001, Zeev Suraski wrote the following:
--
Zeev,
while I'll applaud to the changes you propose, I suggest this
happens in 4.1. I know, this is really a cosmetic change only,
and doesn't justify the bump from the
From: [EMAIL PROTECTED]
Operating system: Linux Mandrake 8.0
PHP version: 4.0.6
PHP Bug Type: MySQL related
Bug description: changing mysql.default_socket in /etc/php.ini doesn't work
I have tried to change MySQL's socket path to something else than the
default. I found
Well, we actually could just bump the version number to 4.1.0 for these
changes alone. I don't think we should wait for *any* of the other changes
that people had in mind for a major or semi major version, but bumping the
number to 4.1.0 instead of staying at 4.0.8 is probably a good idea.
On Thu, 26 Jul 2001, Zeev Suraski wrote:
But in this case someone has gone to the trouble to figure out what
empty() does. And generally they use empty() on things that come from the
user anyway. I don't think I have ever seen people use empty() to check
to see if they themselves have set
accept_parameters($user_string); // or something similar
register_globals off.
$user_string=$HTTP_POST_VARS[user_string];
This accomplishes the same thing as your example, and doesn't
introduce any new syntax... I don't really see the advantage of the
accept_parameters idea.
Well, the
Alexander Merz wrote:
Please, could you use relative specifications (font-size: small)
instead of absolute (font-size: 11px) in the css? It's more
user-friendly and i don't have to look for my eyeglasses each time.
Unfortunately, this isn't consistent cross-platform.
ID: 12415
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: MySQL related
Operating System: Linux Mandrake 8.0
PHP Version: 4.0.6
New Comment:
are you sure PHP actually reads that php.ini? you can see the location where PHP looks
for the file in the
From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0 Workstation
PHP version: 4.0.6
PHP Bug Type: OCI8 related
Bug description: OleMainThreadWndName when using OCIFetchInto statement
OS: Windows NT 4.0 Workstation
Webserver: Apache 1.3
Database: Oracle 8.1.7
PHP
ID: 12415
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: MySQL related
Operating System: Linux Mandrake 8.0
PHP Version: 4.0.6
New Comment:
Found the problem. There was a missing ; .
I thought ;'s are only used for comments...
Previous Comments:
Hello,
I did some further investigation into the opendir() / readdir()
weirdness with the latest CVS on Win32 I reported earlier.
?php
$files = scan_directory('g:/');
function scan_directory($directory) {
static $files;
if (!isset($files)) {
ID: 12416
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: OCI8 related
Operating System: Windows NT 4.0 Workstation
PHP Version: 4.0.6
New Comment:
Additional information
Correct Apache version: 1.3.12
The error.log of Apache displays the following
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Pro (SR-1)
PHP version: 4.0.6
PHP Bug Type: Unknown/Other Function
Bug description: PHP/Apache load-time error
Apache 1.3.20, built from source (MSVC 6.0 Ent) from apache.org.
PHP 4.0.6 binary from php.net.
I didn't
At 08:48 26/07/2001, Rasmus Lerdorf wrote:
Just replace your if ($ok) with if (!empty($ok)), and you have a perfect
exploitable code that produces no warnings.
But in this case someone has gone to the trouble to figure out what
empty() does. And generally they use empty() on things
At 10:35 7/27/2001, Rasmus Lerdorf wrote the following:
--
I actually think that turning E_NOTICE on is going to have a huge effect on
a mind boggling number of scripts, probably on the same order of magnitude
as setting
At 01:35 27/07/2001, Rasmus Lerdorf wrote:
I think you missed my point. People use empty() and isset() on a variable
to check to see if that variable was set by the user. As such that
variable is unclean and whether it came in via register_globals or not is
quite irrelevant. If it is unclean
Yes $PHP_SELF exists but it contains just the actual script. And therefore i
missed
a function for extracting filenames from urls. I needed to extract the
scriptname from
the url to identify the navigation position
marcus
Stig S. Bakken [EMAIL PROTECTED] wrote in message
[EMAIL
ID: 12417
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Unknown/Other Function
Operating System: Windows 2000 Pro (SR-1)
PHP Version: 4.0.6
New Comment:
see http://www.php.net/bugs.php?id=8799
if that doesn't fix your problem, reopen the bug report.
At 01:35 27/07/2001, Rasmus Lerdorf wrote:
I think you missed my point. People use empty() and isset() on a variable
to check to see if that variable was set by the user. As such that
variable is unclean and whether it came in via register_globals or not is
quite irrelevant. If it is
* Rasmus Lerdorf wrote:
significantly more secure PHP scripts out there. It will simply cause
scripts to break in non-obvious ways and the knee-jerk fix will be to
swear at those annoying PHP folks and then turn register_globals on, or
they will do something like:
I fully agree here with Rasmus and I also think this will
be the workaround for most people -- if one _does_ care
about security, he even knows what and how to do nowadays.
I don't think turning register_globals to off will evangelize
people to develop more secure scripts/applications.
From: [EMAIL PROTECTED]
Operating system: Suse 7.1
PHP version: 4.0.6
PHP Bug Type: DBM/DBA related
Bug description: ndbm - driver initialization
$handle = dbm_open(/usr/local/berkeley/nu, c, ndbm);
Error:
Warning: driver initialization failed in
At 03:09 27/07/2001, Rasmus Lerdorf wrote:
At 01:35 27/07/2001, Rasmus Lerdorf wrote:
I think you missed my point. People use empty() and isset() on a variable
to check to see if that variable was set by the user. As such that
variable is unclean and whether it came in via
Guys,
Please read the advisory. You simply can't say that register_globals=off
wouldn't have resulted in more secure apps, because there are *3* examples
(or more, I don't remember) there of applications that would have not been
exploitable had register_globals=on was in effect!
Unless we
At 20:22 02/01/1999, Peter Petermann wrote:
I fully agree here with Rasmus and I also think this will
be the workaround for most people -- if one _does_ care
about security, he even knows what and how to do nowadays.
I don't think turning register_globals to off will evangelize
people
At 03:36 27/07/2001, Zeev Suraski wrote:
Guys,
Please read the advisory. You simply can't say that register_globals=off
wouldn't have resulted in more secure apps, because there are *3* examples
(or more, I don't remember) there of applications that would have not been
exploitable had
ID: 12289
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4.0.5
New Comment:
This didn't solve the problem. As I mentioned before, all include-files are
encapsulated in
Peter Petermann wrote:
I fully agree here with Rasmus and I also think this will
be the workaround for most people -- if one _does_ care
about security, he even knows what and how to do nowadays.
I don't think turning register_globals to off will evangelize
people to develop more secure
register_globals is off? Of course not, but it's definitely going to knock
down a huge amount of exploits in their apps, and there are good chances
that these would be the only exploits in it.
as rasmus wrote,
this would only result in users using foreach to do that.
you cant fight
what we could do to make people to write more secure script is:
- telling them to do so,
- telling them what is insecure
- telling them why something is insecure
- writing a special type of documentation, about how to write secure
scripts
Please, can you say beginner? Once people
At 20:53 02/01/1999, Peter Petermann wrote:
register_globals is off? Of course not, but it's definitely going to
knock
down a huge amount of exploits in their apps, and there are good chances
that these would be the only exploits in it.
as rasmus wrote,
this would only result in users
At 20:58 02/01/1999, Peter Petermann wrote:
i dont think it is easier to write more secure applications
with turning a feature of.
Read the advisory before your next post or I'll have Kristian smack you the
next time he sees you! :)
Zeev
--
PHP Development Mailing List http://www.php.net/
* Zeev Suraski wrote:
equivalent to shipping cars without brakes. You hope that the user would
be bright enough to install brakes,
Hoping that is not enough. If you really change the
behaviour to ship PHP with register_globals to off,
then I suggest you should also ship some README_Security
Peter Petermann wrote:
i dont think it is easier to write more secure applications
with turning a feature of.
In this particular case, it would. There are several reported cases of
security-holes caused by this feature. Without it, there would be fewer
insecure PHP-applications out there.
Changing to register globals=off surely does very little in
terms of security for the easily fakeable GPC variables.
Maybe not for these variables, but other variables used in your script
cannot be faked by passing them as HTTP_POST_VARS.
e.g., with register_globals=off
if
On Friday 27 July 2001 12:51, Marc Boeren wrote:
if ($internal_variable == 'whatever') {
// do something, knowing that a user could never have set this
}
The second check is where a lot of scripts are exploitable, I think, if
register_globals=on, because programmers do not expect
On Fri, Jul 27, 2001 at 08:08:37AM +0100, Anil Madhavapeddy wrote :
Alexander Merz wrote:
Please, could you use relative specifications (font-size: small)
instead of absolute (font-size: 11px) in the css? It's more
user-friendly and i don't have to look for my eyeglasses each time.
(b) As I said, if someone wants to use a gun to shoot himself in the head,
he's welcome to do so. The least we could do is hand him the gun safely
pointed in the other direction, and not point it to his brain.
we are not talking about people who want to have security holes, we are
talking
-- php-4.0.6/Zend/zend_alloc.c (160) ---
if (!p) {
fprintf(stderr,FATAL: emalloc(): Unable to allocate %ld bytes\n,
(long) size);
#if ZEND_DEBUG defined(HAVE_KILL) defined(HAVE_GETPID)
kill(getpid(),
During my test with the pushErrorHandling and popErrorHandling I found
strange behavoirs of the PHP array functions (I use last cvs php under
Linux).
1) array_pop() bug:
?php
$a = array();
$a[] = array('foo', 'bar');
print_r($a);
$a[] = array('foo2', 'bar2');
print_r($a);
$a = array_pop($a);
From: [EMAIL PROTECTED]
Operating system: mandrake 7.1
PHP version: 4.0.6
PHP Bug Type: Compile Failure
Bug description: lmysqlclient: no reference for compress and uncompress
I tried to install php as static module to apache.
But there was a problem in the libmysqlclient.
On Fri, 27 Jul 2001, Zeev Suraski wrote:
(a) How about just setting register_globals to on? We're not talking about
taking this option away, for now, just turn it off by default.
(b) As I said, if someone wants to use a gun to shoot himself in the head,
he's welcome to do so. The least we
I don't see any error in the output. What did you expect?
At 14:30 7/27/2001, Tomas V.V.Cox wrote the following:
--
During my test with the pushErrorHandling and popErrorHandling I found
strange behavoirs of the PHP array functions (I
ID: 12394
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating System: Windows NT4.0
PHP Version: 4.0.6
New Comment:
Excuse me, but this was a bloody amateur failure !!!
The result is an object, so what to do is:
for ($count = 1;
ID: 12394
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: MySQL related
Operating System: Windows NT4.0
PHP Version: 4.0.6
Previous Comments:
[2001-07-26
Cynic wrote:
I don't see any error in the output. What did you expect?
At 14:30 7/27/2001, Tomas V.V.Cox wrote the following:
--
During my test with the pushErrorHandling and popErrorHandling I found
strange behavoirs of the PHP
At 14:53 7/27/2001, Tomas V.V.Cox wrote the following:
--
Cynic wrote:
I don't see any error in the output. What did you expect?
At 14:30 7/27/2001, Tomas V.V.Cox wrote the following:
From: [EMAIL PROTECTED]
Operating system: Window 2000 Server
PHP version: 4.0.6
PHP Bug Type: IIS related
Bug description: The w3swc service is gaving error cannot load isapidll
?phpinfo();?
--no module I used
--I want to work with php_oci8.dll but not getting any
From: [EMAIL PROTECTED]
Operating system: Window 2000 Server
PHP version: 4.0.6
PHP Bug Type: IIS related
Bug description: The w3swc service is gaving error cannot load isapidll
?phpinfo();?
--no module I used
--I want to work with php_oci8.dll but not getting any
ID: 12422
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: IIS related
Operating System: Window 2000 Server
PHP Version: 4.0.6
New Comment:
submitted twice
Previous Comments:
ID: 11813
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: GD related
Operating System: Win NT 4.0
PHP Version: 4.0.6
Previous Comments:
[2001-06-30 19:20:05] [EMAIL PROTECTED]
ID: 11929
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: GD related
Operating System: Linux; Slackware 8.0/2.4.5
PHP Version: 4.0.6
New Comment:
Use the freetype 1.x libs. And ask further install
questions on [EMAIL PROTECTED]
Previous Comments:
Crashes (signal 11) on file upload using multipart form data.
Worked with 4.0.4pl1, haven't tried 4.0.5, crashed with 4.0.6 and latest
CVS since.
Hello,
Has this been addressed at all?
In any case, when the PHP multipart form handling functions worked properly
(v4.04, etc.) , how did they
From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version: 4.0.6
PHP Bug Type: *General Issues
Bug description: float point assignment error
It's easy to describe:
echo odbc_result($ref, column);
$a = (double) odbc_result($ref, column);
echo/. $a;
Cynic wrote:
1) array_pop() bug:
?php
$a = array();
$a[] = array('foo', 'bar');
print_r($a);
$a[] = array('foo2', 'bar2');
print_r($a);
$a = array_pop($a);
print_r($a);
?
so, you're questioning the order of the retval assignment, and the
popped array?
$a =
From: [EMAIL PROTECTED]
Operating system: Linux - Red Hat 7.1
PHP version: 4.0.6
PHP Bug Type: Apache related
Bug description: apache core dumps when started with a php.ini in /usr/local/lib
Just Compile 4.0.6 (Apache-1.3.20 DSO) amazingly all the
stuff I compiled in
Peter Petermann wrote:
I fully agree here with Rasmus and I also think this will
be the workaround for most people -- if one _does_ care
about security, he even knows what and how to do nowadays.
I don't think turning register_globals to off will evangelize
people to develop more
ID: 12303
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Apache related
Operating System: slackware linux
PHP Version: 4.0.6
New Comment:
Does this happen with older PHP versions? Like PHP 4.0.5?
And could you also try the latest CVS snapshot from
Peter Petermann wrote:
i dont think it is easier to write more secure applications
with turning a feature of.
In this particular case, it would. There are several reported cases of
security-holes caused by this feature. Without it, there would be fewer
insecure PHP-applications out
ID: 12303
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Apache related
Operating System: slackware linux
PHP Version: 4.0.6
New Comment:
And please provide a gdb backtrace of the crash.
Previous Comments:
ID: 11754
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Program Execution
Operating System: Win32 (2000)
PHP Version: 4.0.6
New Comment:
no user feedback. if the bug still exists, please reopen it.
Previous Comments:
This is a confirmation e-mail for your request.
You can come anytime and claim your FREE Sex Toys at
http://www.freevibrator.com
All Free Sex Toys we feature are absolutly free with no purchase necessary whatsoever.
(Small reasonable shipping charges apply)
Thank You for subscribing to
ID: 11764
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Windows NT Workstation 4.0
PHP Version: 4.0.6
New Comment:
no user feedback. if this problem still persists, please reopen the bug.
Previous
ID: 9860
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Dynamic loading
Operating System: WinNT 4.0 SP6
PHP Version: 4.0.4pl1
Previous Comments:
[2001-06-12 10:50:09]
¶Ç¯u¸¹½X¥X°â
§Ú¦³¥_°Ï02_¶}ÀY¶Ç¯u¸¹½X¡A¦@¬°77270µ§
¬O§Ú±q¦UÓ¦P·~¤½·|¡B¹q¸Üï¡B¶À¶¡B¼x«H©Ò¡B
ºô»Úºô¸ô¡A¥úºÐ¤ù...µ¥µ¥¡A
¸g¦~²Ö¤ë¤@µ§¤@µ§¥´¤J¦¬¶°¤U¨Óªº¡A¶O¤F«Ü¤jªº¥\¤Ò¡C
¥úªá¿ú¶R¼x«H©Ò¥Xªºªº¥U¤l¡A´Nªá¤F¤£¤Ö¿ú¡A
¦A¸g¹L²Îp¤èªk¾ã²z¡A©Ò¥H¨S¦³¥ô¦ó¤@µ§¬O«½Æªº¡A
From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.0 2.2.16-22smp
PHP version: 4.0.6
PHP Bug Type: Unknown/Other Function
Bug description: Critical PHP bug while processing big POST data (10K)
I have configured PHP4 to process POST data less than 800 (phpinfo()
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.0.6
PHP Bug Type: Feature/Change Request
Bug description: I want 'echoln'
Is there something like an 'echoln'?
I use echo $var,'\n' quite often,
so an 'echoln' would be very handy.
Or even better would
Is all of this springing from that security advisory that was published a
short while ago?
I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).
Also, wasn't that advisory just written by some guy? Its not like W3C is
writing a web
On Fri, 27 Jul 2001, Zeev Suraski wrote:
It will simply cause
scripts to break in non-obvious ways and the knee-jerk fix will be to
swear at those annoying PHP folks and then turn register_globals on, or
they will do something like:
foreach($HTTP_POST_VARS as $key=$val) $$key =
From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version: 4.0.6
PHP Bug Type: Class/Object related
Bug description: is_subclass_of
if I have a class like this
class PEAR_Error {
Note the uppercase !
and $a=new PEAR_Error();
if I do
ID: 12003
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: InterBase related
Operating System: Linux Red Hat 7.1 (2.4.2)
PHP Version: 4.0.6
New Comment:
status - open.
Previous Comments:
From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version: 4.0.6
PHP Bug Type: iPlanet related
Bug description: IPLANET JVM abort
If I compile PHP with the following options
./configure --with-nsapi=/usr/netscape/web-server --enable-libgcc
--with-zlib=/usr/local
I have been watching this thread for too long and I can no longer resist commenting.
If a programmer does not initialize SECURE variables properly, he is going to make far
worse
security decisions in his software. Next thing we are going to hear is that php does
not auto TAINT check
parsed
ID: 12314
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: WinME
PHP Version: 4.0.6
New Comment:
Have you tried adding the drive name to the paths? ie.
include_path=.;c:\my\own\includes\;d:\some\other\stuff\
As this
ID: 12372
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: LDAP related
Operating System: RedHat 7.0
PHP Version: 4.0.6
Previous Comments:
[2001-07-26 11:44:29]
ID: 12317
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: *General Issues
Operating System: any
PHP Version: 4.0.6
New Comment:
forwarded to [EMAIL PROTECTED] which handles these problems.
Previous Comments:
ID: 10904
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating System: WINNT SP4
PHP Version: 4.0.5
New Comment:
status: open
Previous Comments:
I was wondering this same thing a while ago.
Nobody bothered to answer to my question if
we should always use the mt_rand() instead of the
system specified ones.. any ideas why not?
--Jani
On 23 Jul 2001 [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux
ID: 12287
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 4.0.6
New Comment:
Get the c-client sources and compile it yourself.
Then copy all the .h files to e.g. /www/c-client/include
and
At 04:33 27/07/2001, Phil Driscoll wrote:
I must be much more stupid than I give myself credit for.
Changing to register globals=off surely does very little in terms of security
for the easily fakeable GPC variables. I can see that for environment
variables the picture is slightly different -
At 04:48 27/07/2001, Peter Petermann wrote:
well, i think you misunderstood me.
we are not talking of a brakeless car, and we are not talking
about a language who is not able to be used secure.
we are talking about something that has the abilities to be secure,
we just need to teach the people
At 07:37 27/07/2001, Rasmus Lerdorf wrote:
I see your point, but I disagree.
Register_globals is a lanugage-feature which can result in
security-gaps when people don't initialize their variables.
It's a common mistake, a pitfall, especially for beginners, that could
be resolved by
ID: 12323
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Output Control
Operating System: Mac OS X
PHP Version: 4.0.6
New Comment:
status: open
Previous Comments:
At 10:19 27/07/2001, Brian Tanner wrote:
Is all of this springing from that security advisory that was published a
short while ago?
I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).
Also, wasn't that advisory just written by some guy?
I'm definitely in favour of that, and some of the other suggestions that
were raised. We won't be able to make all steps at once, but whomever can
contribute is obviously quite welcome to do so.
Zeev
At 04:15 27/07/2001, Björn Schotte wrote:
* Zeev Suraski wrote:
equivalent to shipping
ID: 6960
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Old Bug Type: *Graphics related
Bug Type: GD related
Operating System: Win 2000
PHP Version: 4.0.2
New Comment:
And this should be fixed (again) in CVS now.
--Jani
Previous Comments:
At 10:01 27/07/2001, Rasmus Lerdorf wrote:
That's also not true. Is using $foo all that better than $_GET[foo]?
For a neophyte user - most definitely.
But it isn't. It's by fixing an inherent design flaw in PHP. The proposed
target situation is *NOT* any more difficult to the users
At 04:51 27/07/2001, Marc Boeren wrote:
Changing to register globals=off surely does very little in
terms of security for the easily fakeable GPC variables.
Maybe not for these variables, but other variables used in your script
cannot be faked by passing them as HTTP_POST_VARS.
e.g., with
ID: 12326
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Session related
Operating System: Windows 2000 Server
PHP Version: 4.0.4
New Comment:
RTFM:
http://www.php.net/manual/en/function.session-register.php
:)
Previous Comments:
On Friday 27 July 2001 17:35, Zeev Suraski wrote:
Have you read the advisory? That's simply not true.
Yes, and I beleive it is true in most cases.
There are two main types of security problems related to this:
(a) Ones that originate in the fact that people don't know they mustn't
trust
At 08:58 27/07/2001, Jason Greene wrote:
I have been watching this thread for too long and I can no longer resist
commenting.
If a programmer does not initialize SECURE variables properly, he is going
to make far worse
security decisions in his software. Next thing we are going to hear is
ID: 12331
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux 2.4.7
PHP Version: 4.0.6
New Comment:
I can not reproduce this with latest CVS.
Could you please try the latest snapshot from http://snaps.php.net/
ID: 12335
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Mail related
Operating System: Sun Solaris 2.6
PHP Version: 4.0.6
New Comment:
So which version of PHP are you using? In your comments
you say 4.0.4 but in the headers there is 4.0.6??
Previous Comments:
That's also not true. Is using $foo all that better than $_GET[foo]?
For a neophyte user - most definitely.
But it isn't. It's by fixing an inherent design flaw in PHP. The proposed
target situation is *NOT* any more difficult to the users than the
situation is today.
Of course it is.
At 10:26 27/07/2001, Phil Driscoll wrote:
On Friday 27 July 2001 17:35, Zeev Suraski wrote:
Have you read the advisory? That's simply not true.
Yes, and I beleive it is true in most cases.
There are two main types of security problems related to this:
(a) Ones that originate in the fact
From: [EMAIL PROTECTED]
Operating system: GNU Linux
PHP version: 4.0.6
PHP Bug Type: MySQL related
Bug description: not valid mysql ressource
$eLink = mysql_connect(...);
.
.
.
class test {
function einTest() {
$eLink = mysql_connect();
Thanks for the cool response Zeev.. I was a little agitated when I wrote
that letter, glad you didn't take it the wrong way.
Again, my position is very simple. I agree that what you are suggesting
would greatly reduce the exploits of the language. Just concerned about the
cost, and if the
This is an important step, that as I said, I wanted to make for years. I
just argue that as protective as you are over register_globals=on, the real
flaw is there, and this is the place it should be fixed. Fixing the fact
that E_NOTICE is on may also be viable, but in practice:
- A huge
From: [EMAIL PROTECTED]
Operating system: GNU Linux
PHP version: 4.0.6
PHP Bug Type: cURL related
Bug description: Curl Crush, CURLOPT_WRITEHEADER
After using curl_setopt - CURLOPT_WRITEHEADER to a valid
filepointer curl somehow crushes.
Excerpt from apache error_log
ID: 12372
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Summary: LDAP calls within a function fail
Status: Open
Bug Type: LDAP related
Operating System: RedHat 7.0
PHP Version: 4.0.6
New Comment:
Sorry my bad
it is not a parse errorI typed FAT FINGERED when I
1 - 100 of 137 matches
Mail list logo
