date:20010729

For those of you who aren't sure where the heck those space-after-comma and 
the other rules are coming from, that's the K&R coding standard, which is 
the coding standard for the php4 repository.   One other rule that's really 
not followed is [3]:

[3] Be generous with whitespace and braces.  Always prefer:

 if (foo) {
 bar;
 }

 to:

 if(foo)bar;

 Keep one empty line between the variable decleration section and
 the statements in a block, as well as between logical statement
 groups in a block.  Maintain at least one empty line between
 two functions, preferably two.

At 20:09 29/07/2001, Zeev Suraski wrote:
>Guys,
>
>Please follow the coding standards as they appear in the CODING_STANDARDS 
>with code you commit to the PHP repository.
>Stuff I noticed while going over large portions of code in the last few days:
>   - open-curly-braces should not appear on the same line as a function 
> declaration, but on the following line
>   - commas (e.g. in function calls or declarations, or macro calls) 
> should be followed by a space.  I.e., foo(a, b, c), never foo(a,b,c).
>
>Going over code which has many different layouts is a real pain.  The code 
>in the php4 repository at least should be consistent.
>
>Thanks,
>
>Zeev
>
>
>--
>PHP Development Mailing List 
>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 
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


At 21:23 29/07/2001, Stephen van Egmond wrote:
>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!";
> }
>}

Umm, there's no need for that code.  $HTTP_POST_FILES can only contain 
uploaded files (I added code that protects $HTTP_*_VARS and 
$HTTP_POST_FILES from the register_global danger around 4.0.3 or so;  Stuff 
in these variables can only come from the real POST/GET/etc. 
sources).  is_uploaded_file() was added only for those who use 
register_globals.

> > 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.

It was just one of the examples to the emergencies that register_globals 
created for us in the past :)

Zeev


-- 
PHP Development Mailing List 
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

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 search&replace 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 
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


> 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.

That's not the case.  The default variable_order is EGPCS which means that
POST variables will always overwrite GET variables of the same name.

-Rasmus


-- 
PHP Development Mailing List 
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

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 
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

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Coding standards (layout)


Guys,

Please follow the coding standards as they appear in the CODING_STANDARDS 
with code you commit to the PHP repository.
Stuff I noticed while going over large portions of code in the last few days:
   - open-curly-braces should not appear on the same line as a function 
declaration, but on the following line
   - commas (e.g. in function calls or declarations, or macro calls) should 
be followed by a space.  I.e., foo(a, b, c), never foo(a,b,c).

Going over code which has many different layouts is a real pain.  The code 
in the php4 repository at least should be consistent.

Thanks,

Zeev


-- 
PHP Development Mailing List 
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


At 02:40 29/07/2001, Sterling Hughes wrote:
> Ahh well, I guess I'll have to commit it before the changes and then
> expect Zeev and Andi to fix it :)

We have no plans to fix those, because they'd require complete rewrites :)

Zeev


-- 
PHP Development Mailing List 
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


It will be completely different, I'm afraid.  Whatever API code's gluing 
your low level code to the engine, will have to be completely rewritten, 
but it'd be a much simpler and easy to write for API.

At 23:03 28/07/2001, 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?
>
> -Sterling
>
>
>--
>PHP Development Mailing List 
>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 
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


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 :)

>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.

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?

Zeev


-- 
PHP Development Mailing List 
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


Generally I agree, except I don't think we should go as far as changing the 
theme of PHP.  Putting form variables into a different space would be the 
simplest and equally secure way to do the trick.

At 08:32 26/07/2001, [EMAIL PROTECTED] wrote:
>Hi Zeev!
>On Thu, 26 Jul 2001, Zeev Suraski wrote:
>
> > At 02:18 26/07/2001, Ron Chmara wrote:
> > >>   If most of the PHP apps out there are or were vulnerable to
> > >> register_globals=on attacks, we can't (shouldn't) blame the whole 
> world,
> > >> but fix the language instead.
> > >
> > >I'd suggest fixing the code religion instead, but changing faiths is 
> hard.
> > >:-) If they aren't checking their vars before processing, no language
> > >would fix it, would it?
> >
> > Most would, actually.  Pretty much any language which requires you to
> > declare variables, or, that doesn't allow external sources to declare
> > variables, does not have this problem.  PHP is quite unique in that sense,
> > which is why I agree that the language is at fault.  Of course, declaring
> > and not initializing your variable is still a programming error, but it's
> > much less severe and much less prone to exploits than this problem.
> >
>May I jump in? :)
>
>As I see it, the security issue is "Untrusted data coming from the user",
>which collects under the "request" term.
>
>What is overwritten? Server vars or user vars, and that's because there's no
>hard separation between them in the "register globals on" case (all in the
>same pot).
>
>So why wouldn't PHP propose a Reques-Response paradigm like ASP,JSP or Zope,
>before we have namespaces and such?
>
>If I say $Request->getAttribute('geez') I am damn sure it comes from the user
>and I consider the value inherently suspicious (i.e. don't just stuck it in
>a mysql_query() string w/o testing.)
>
>This can be done at PHP level or language level (where other security tests
>can be addressed.)
>
>The best teaching the pear/php devs can give to the user in the security issue
>is to promote best programming practices, and IMO this is one of them;
>otherwise they'll have to gulp bitter advisories about this and that popular
>PHP application having an ungly bug (see phpMyAdmin, IMP, Phorum, etc.)
>
>
>my 2c
>
>-- teodor
>
>--
>PHP Development Mailing List 
>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 
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


What you ignored completely are three facts:
- 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.
- 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.

Zeev

At 11:42 29/07/2001, Stephen van Egmond wrote:
>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 
>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12209 Updated: apxs not creating libphp4.so during 'make install'

2001-07-29 Thread avsm


ID: 12209
Updated by: avsm
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Apache related
Operating System: OpenBSD 2.9
PHP Version: 4.0.6


Previous Comments:


[2001-07-17 11:52:05] [EMAIL PROTECTED]

make install:
()
Making install in .
/usr/local/archive/php/php-4.0.6/build/shtool mkdir -p "/usr/local/apache/libexec" && 
/usr/local/apache/bin/apxs -S LIBEXECDIR="/usr/local/apache/libexec" -i -a -n php4 
libs/libphp4.so
[activating module `php4' in /usr/local/apache/conf/httpd.conf]
cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so
apxs:Break: Command failed with rc=16777215
*** Error code 1

Stop in /usr/local/archive/php/php-4.0.6 (line 39 of Makefile).
*** Error code 1

Stop in /usr/local/archive/php/php-4.0.6 (line 37 of 
/usr/local/archive/php/php-4.0.6/build/rules.mk).
---
./configure \
--with-mysql=/usr/local/mysql \
--with-apxs=/usr/local/apache/bin/apxs \
--with-mm=/usr/local
---
# verified httpd is capable of php as dso:
/opt/apache/bin/httpd -l
# saw http_core.c & mod_so.c compiled in
---
/usr/local/apache/bin/apxs -q:
CC = gcc
CFLAGS = -DMOD_SSL=208104
CFLAGS_SHLIB   = -DMOD_SSL=208104 -DEAPI -DUSE_EXPAT -I../lib/expat-lite
LD_SHLIB   = gcc
LDFLAGS_SHLIB  = -shared -fPIC -DSHARED_MODULE
LIBS_SHLIB = 
TARGET = httpd
SBINDIR= /usr/local/apache/bin
INCLUDEDIR = /usr/local/apache/include
LIBEXECDIR = /usr/local/apache/libexec
SYSCONFDIR = /usr/local/apache/conf
PREFIX = /usr/local/apache
---
thank you for your thoughts! i appreciate it...





Edit this bug report at http://bugs.php.net/?id=12209&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12209 Updated: apxs not creating libphp4.so during 'make install'

2001-07-29 Thread avsm


ID: 12209
Updated by: avsm
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: OpenBSD 2.9
PHP Version: 4.0.6
New Comment:

Try using the port of PHP4, as detailed in:
http://www.php.net/manual/en/install.openbsd.php

Previous Comments:


[2001-07-17 11:52:05] [EMAIL PROTECTED]

make install:
()
Making install in .
/usr/local/archive/php/php-4.0.6/build/shtool mkdir -p "/usr/local/apache/libexec" && 
/usr/local/apache/bin/apxs -S LIBEXECDIR="/usr/local/apache/libexec" -i -a -n php4 
libs/libphp4.so
[activating module `php4' in /usr/local/apache/conf/httpd.conf]
cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so
apxs:Break: Command failed with rc=16777215
*** Error code 1

Stop in /usr/local/archive/php/php-4.0.6 (line 39 of Makefile).
*** Error code 1

Stop in /usr/local/archive/php/php-4.0.6 (line 37 of 
/usr/local/archive/php/php-4.0.6/build/rules.mk).
---
./configure \
--with-mysql=/usr/local/mysql \
--with-apxs=/usr/local/apache/bin/apxs \
--with-mm=/usr/local
---
# verified httpd is capable of php as dso:
/opt/apache/bin/httpd -l
# saw http_core.c & mod_so.c compiled in
---
/usr/local/apache/bin/apxs -q:
CC = gcc
CFLAGS = -DMOD_SSL=208104
CFLAGS_SHLIB   = -DMOD_SSL=208104 -DEAPI -DUSE_EXPAT -I../lib/expat-lite
LD_SHLIB   = gcc
LDFLAGS_SHLIB  = -shared -fPIC -DSHARED_MODULE
LIBS_SHLIB = 
TARGET = httpd
SBINDIR= /usr/local/apache/bin
INCLUDEDIR = /usr/local/apache/include
LIBEXECDIR = /usr/local/apache/libexec
SYSCONFDIR = /usr/local/apache/conf
PREFIX = /usr/local/apache
---
thank you for your thoughts! i appreciate it...





Edit this bug report at http://bugs.php.net/?id=12209&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Bug #12166 Updated: SQL_CUR_DEFAULT constant not defined in php_odbc.dll

2001-07-29 Thread jlim


> ID: 12166
> Updated by: kalowsky
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Feedback
> Bug Type: ODBC related
> Operating System: Windows ME
> PHP Version: 4.0.6
> New Comment:
> 
> 
> Which docs are you referring to?  The ODBC docs for PHP?  The ODBC v3 docs? 
> The ODBC v3.5 docs?
> 

Whoops, sorry for the name change. Silly me.

I meant the ODBC docs in the PHP manual.

- John


> please note that my name is kalowsky, not kowalsky.
> 
> 
> 
> Previous Comments:
> 
> 
> [2001-07-16 22:32:16] [EMAIL PROTECTED]
> 
> Hi Kowalsky
> 
> If you check in microsoft's  sqlext.h you will see that
> 
> SQL_CUR_DEFAULT is set to SQL_CUR_USE_DRIVER 
> 
> so it is a constant. Also if you check the odbc_connect( ) docs, it says
> that SQL_CUR_DEFAULT is an acceptable parameter to pass into odbc_connect().
> So it should be defined, or the documentation be corrected.
> 
> Regards, John
> 
> 
> 
> [2001-07-16 08:31:20] [EMAIL PROTECTED]
> 
> this is supposed to be defined by your ODBC driver, not by PHP... after all,
> how is PHP to know what your DB's default cursor is?
> 
> 
> 
> [2001-07-14 11:14:19] [EMAIL PROTECTED]
> 
> SQL_CUR_DEFAULT, which is a constant that can be passed into odbc_connect,
> is not defined in the odbc extension. I get a warning that it an undefined
> constant when I use it. A quick check in the source code confirmed it. 
> 
> 
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
> http://bugs.php.net/?id=12166&edit=2
> 



---
"Stressed spelled backwards is desserts."
[EMAIL PROTECTED]   NATSOFT MALAYSIA  (60)3-706 1216
 
   Visit this web site for Asian and local Internet news
 http://webfeet.editthispage.com/
   My PHP website:
 http://php.weblogs.com/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] JAVA support.

2001-07-29 Thread SlowPork




Hello.I instantiated new class [ 
eg.  
]. 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.1phpinfo() shows Java section 
fine.java.class.path   
/usr/local/lib/php/php_java.jar:/usr/local/linux-jdk1.3.1/jre/lib/rt.jarjava.home  
/usr/local/linux-jdk1.3.1java.library 
libjava.sojava.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_threadsFrom, 
php.inijava.home=/usr/local/linux-jdk1.3.1java.class.path=/usr/local/lib/php/php_java.jar:/usr/local/linux-jdk1.3.1/jre/lib/rt.jarextension_dir=/usr/local/lib/php/20001222extension=libphp_java.sojava.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_threadsjava.library=libjava.soI 
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# kldstatId Refs 
Address    Size 
Name 1    3 0xc010 38c5f4   
kernel 2    1 0xc0d47000 3000 
daemon_saver.ko  (screen saver) 3    1 0xc0d4c000 
12000    linux.koI 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_threadsI 
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 
addressThank you. slowpork at 
hotmail.com

[PHP-DEV] php+apache2 anyone?


Anyone got an Apache2 running (which one) with PHP (which one) ?
thx

ciao

-- teodor

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12460: ZLIBG(v) redefined in ext/zlib/php_zlib.h


From: [EMAIL PROTECTED]
Operating system: SuSE  7.1
PHP version:  4.0CVS-2001-07-29
PHP Bug Type: Compile Failure
Bug description:   ZLIBG(v) redefined in ext/zlib/php_zlib.h

In file included from zlib.c:48:

php_zlib.h:74: warning: `ZLIBG' redefined

php_zlib.h:73: warning: this is the location of the previous definition

zlib.c: In function `php_zlib_init_globals':

zlib.c:152: `zend_zlib_globals' undeclared (first use in this function)



[so on]

teo:/usr/src/php4-200107291635 # cat config.nice

#! /bin/sh

#

# Created by configure



'./configure' \

'--with-apxs2=/usr/local/apache2/bin/apxs' \

'--enable-debug' \

'--with-xslt-sablot' \

'--with-zlib' \

'--with-dom' \

'--with-mysql=/usr/local' \

'--disable-posix' \

'--enable-trans-sid' \

'--enable-shmop' \

'--enable-sockets' \

'--enable-wddx' \

"$@"



teo:/usr/src/php4-200107291635 # /usr/local/apache2/bin/httpd -v

Server version: Apache/2.0.23-dev

Server built:   Jul 30 2001 01:04:48


-- 
Edit bug report at: http://bugs.php.net/?id=12460&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12457 Updated: Mail()

2001-07-29 Thread mfischer


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 





Edit this bug report at http://bugs.php.net/?id=12457&edit=1


-- 
PHP Development Mailing List 
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


Alexander Merz wrote:
> 
> > > 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?

Avoid font-size in CSS you mean?  It would be simpler to avoid CSS at
all if you ask me.  But the world is not that simple, you end up with
weird compromises when you want your site to look nice "all" browsers.

 - Stig

-- 
PHP Development Mailing List 
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

2001-07-29 Thread Sterling Hughes


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 
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


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.

 - Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12455 Updated: Srand and shuffle give odd results

2001-07-29 Thread sulka


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:



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; $i<6; $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=12455&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12403 Updated: VARIANT.c : error C2065 'CP_SYMBOL' : undeclared identifier

2001-07-29 Thread phanto


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=12403&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12403 Updated: VARIANT.c : error C2065 'CP_SYMBOL' : undeclared identifier

2001-07-29 Thread phanto


ID: 12403
Updated by: phanto
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: NT 4
PHP Version: 4.0.6
New Comment:

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.

Previous Comments:


[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=12403&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

2001-07-29 Thread CVS Account Request


Full name: Halil Sen
Email: [EMAIL PROTECTED]
ID:halilsen
Purpose:   Maintaining www.php.net,
Developing the PHP runtime


-- 
PHP Development Mailing List 
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

Stig S. Bakken ([EMAIL PROTECTED]) wrote:
> Uhm, why not simply run PHP scripts from cron?  Or did you want
> something inside a web server environment?

I personally have been looking for something similar.  AOLServer has
this facility:
http://www.aolserver.com/docs/tcldev/tapi-114.htm

and believe me, it rocks.

The problem it solves is this: in larger production environments,
people have usually figured out how to use CVS to do revision control
for what goes up on a web site.  cron is one of those annoying things
that has to live outside of CVS.  In a team where there can be many
people on the web server, people DO edit the cron tab, forget to save
their changes, and people only discover the problem when something
stops working.

FWIW, I'm designing a few improvements to the Apache SAPI
implementation that might make this improvement. I don't think it
belongs in the language itself though.

- Steve

-- 
PHP Development Mailing List 
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

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12457: Mail()

2001-07-29 Thread surfer182


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 
-- 
Edit bug report at: http://bugs.php.net/?id=12457&edit=1


-- 
PHP Development Mailing List 
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

2001-07-29 Thread Chuck Hagenbuch


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 
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


> > 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 
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

2001-07-29 Thread Chuck Hagenbuch


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 
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


> 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.
>   
>   ...
>   

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Security techniques


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. 

...


   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 
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 (backward fix)


Hi Ron!
On Sat, 28 Jul 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 :-)

php_value auto_prepend_file globals_fix.php


[globals_fix.php]

extract($HTTP_GET_VARS);
extract($HTTP_POST_VARS);
extract($HTTP_COOKIE_VARS);
etc.
now they all work with register_globals off
erm? :)

-- teodor

-- 
PHP Development Mailing List 
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


Hi Zeev!
On Thu, 26 Jul 2001, Zeev Suraski wrote:

> At 02:18 26/07/2001, Ron Chmara wrote:
> >>   If most of the PHP apps out there are or were vulnerable to 
> >> register_globals=on attacks, we can't (shouldn't) blame the whole world, 
> >> but fix the language instead.
> >
> >I'd suggest fixing the code religion instead, but changing faiths is hard. 
> >:-) If they aren't checking their vars before processing, no language 
> >would fix it, would it?
> 
> Most would, actually.  Pretty much any language which requires you to 
> declare variables, or, that doesn't allow external sources to declare 
> variables, does not have this problem.  PHP is quite unique in that sense, 
> which is why I agree that the language is at fault.  Of course, declaring 
> and not initializing your variable is still a programming error, but it's 
> much less severe and much less prone to exploits than this problem.
> 
May I jump in? :)

As I see it, the security issue is "Untrusted data coming from the user",
which collects under the "request" term.

What is overwritten? Server vars or user vars, and that's because there's no
hard separation between them in the "register globals on" case (all in the
same pot).

So why wouldn't PHP propose a Reques-Response paradigm like ASP,JSP or Zope,
before we have namespaces and such?

If I say $Request->getAttribute('geez') I am damn sure it comes from the user
and I consider the value inherently suspicious (i.e. don't just stuck it in
a mysql_query() string w/o testing.)

This can be done at PHP level or language level (where other security tests
can be addressed.)

The best teaching the pear/php devs can give to the user in the security issue
is to promote best programming practices, and IMO this is one of them;
otherwise they'll have to gulp bitter advisories about this and that popular
PHP application having an ungly bug (see phpMyAdmin, IMP, Phorum, etc.)


my 2c

-- teodor

-- 
PHP Development Mailing List 
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?


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 
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] function basename()


Hi Marcus!
On Thu, 26 Jul 2001, Marcus wrote:

> shouldn't the function basename() return only the
> script part and not the query part?
I guess basename() is a filesistem function, and hence it doesn't make sense
to care about `query string' cause in the file systems there are no such
things.

I guess you are trying to determine the name of the script from the query
string or what exactly? If so, it's quite simple to use basename(__FILE__);

-- teodor

-- 
PHP Development Mailing List 
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 (isset stuff)


Hi Phil!
On Sat, 28 Jul 2001, Phil Driscoll wrote:

> > That's not going to find half, or a quarter, or whatever of the problems,
> > since PHP has tools to cleanly handle undefined variables - namely isset()
> > and empty().  They, or at least isset(), are quite popular.
> 
> I always use something like:
> 
> if(!isset($Thing) /*and possibly some range checking*/))
>  $Thing="sensible default";
> 
> In no way is
> 
> if(!isset(_GET['Thing']) /*and possibly some range checking*/))
> {
>  $Thing="sensible default";

well, lemme tell you my favourite:
$defRequest = array ('thing1' => '', 'thing2'=>'' /* ... */);
$myRequest = array_merge ($defRequest, $HTTP_GET_VARS); /* or POST*/;

This way you'll be able to simply say:
if ($myRequest[] != ) {
// do something
}

and be sure you have something there.

> any more secure (nor would it be if I wrote "sensible default" back to _GET.
> 
> Anyway, to check my sanity i have reread the security advisory which I first 
> read on the day it was published, and I am even more conviced now that 
> register globals=off has the tiniest of effects for gpc variables wheras 
> E_NOTICE has a massive effect.
> 
> Here are the examples from the advisory:
> 
> --
> if ($pass === "hello") //= corrected to ===
>$auth = 1;
>   ...
>   if ($auth == 1)
>echo "some important information";
>  ?>
> 
> replace $pass with _GET['pass']  and the code is 
> equally insecure. Turn E_NOTICE on and the novice programmer will get a 
nope,
in the first case I can say http://your.site/your_page.php?pass=whatever&auth=1

> warning message for the unset $pass.
> --
> if (!($fd = fopen("$filename", "r"))
>echo("Could not open file: $filename\n");
>  ?>
> 
> replace $filename with _GET['filename'] and this lunatic piece of code 
> remains a lunatic piece of code. If $filename is not meant to be coming from 
> the outside world then with E_NOTICE on there would be a warning message for 
> the unset filename.
The issue here was as always 'untrusted user data' used as trusted (I can say
?fielname='../../../etc/passwd' etc.)
And *maybe* seeing :
$fd = fopen ($_GET['filename'],'r');

something will click in the mind of the programmer ('geez, wait, this is
 *straight* form the request[is sais GET], what if...)

> --
> include($libdir . "/languages.php");
>  ?>
> Ok, with register_globals=off then $libdir could not be directly overwritten 
> from outside (unless there was some code which made that happen) however 
> E_NOTICE would generate a warning for an unset $libdir
Again, it will be set, and no notice will pop up, but it will be set by the
evil guy.

The advisory was not like one from eEye as clear and professional, but had a
very well defined point. And sadly, it was right.

-- teodor

-- 
PHP Development Mailing List 
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

2001-07-29 Thread Sascha Schumann

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 
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

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12455 Updated: Srand and shuffle give odd results

2001-07-29 Thread rasmus


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:



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; $i<6; $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=12455&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Object Overloading Interface

2001-07-29 Thread Sterling Hughes


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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

2001-07-29 Thread CVS Account Request


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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Latest thread safety patch

2001-07-29 Thread Sterling Hughes


Howdy,

Just been going through the latest thread safety patch and I was
wondering why the EXT* macro's have been deleted in favor of
directly passing the zend_*_globals *name (take a look at OCI8 for
more of what I'm talking about).

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] How is a Syntax Highlight editor made ?

2001-07-29 Thread Arcadius A.


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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues


At 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 
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

2001-07-29 Thread Phil Driscoll

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. 
People who code sloppily, code sloppily, the warning messages will get out. 
Even people who code well but don't test under E_WARNING will find that 
E_WARNING is their friend. I don't think that the typical uses of isset and 
empty actually serve to hide the warning messages that would appear in 
vulnerable code.

Anyway, I'll shut up now and leave you in peace :)

-- 
Phil Driscoll

-- 
PHP Development Mailing List 
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

Note again that we should not see this change for what it isn't - it *is* 
going to be a painful move for those who actually do it.  The reason for 
this is that register_globals=on silently encouraged writing of faulty 
code.  In turn, this means that people would have to go over their code in 
order to fix these issues, and no automated way of any kind can help.  The 
import_globals with prefix globbing can make the migration slightly less 
painful, because you can just add a common prefix to all of your variables 
instead of converting them to array index references, but you still have to 
go over all of your code if you actually want to review it for this issue.

That said, as I've been arguing in the last few days, this change is well 
worth the pain it'd cause.

As a matter of fact, I think that the easiest API would actually be instead 
of a prefix globbing, the 2nd argument of import_globals() would actually 
force a prefix onto the variable name.  I.e.,

import_globals("GPC", "form_");

would register all of the GPC variables with a form_ prefix, e.g.,  will end up being
$form_foo

import_globals("GPC", "");
would work, but generate an E_NOTICE

I think that would actually be easier than the pattern matching approach, 
because using this method, the users only have to change their form 
handling scripts, whereas using the glob approach, they also have to change 
their forms.

Zeev

At 04:20 29/07/2001, Jeffrey A.Stuart wrote:
>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 
>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 
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


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 
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

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

At 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12456: PHP does not compile with --with-apxs2

2001-07-29 Thread sinistre


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=12456&edit=1


-- 
PHP Development Mailing List 
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

2001-07-29 Thread Alexander Merz


> > 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 
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

2001-07-29 Thread Max Landborn

> 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 
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


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 
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


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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Artikel 'Startseite' per E-Mail

2001-07-29 Thread redaktion

Guten Tag,

vom Rechner 217.1.142.1 hat jemand Ihnen folgende Seite geschickt:

http://phpcenter.de/index.php3

Title: PHP-Center -
Startseite

Suche:
Seite verschickenQuickref deen

Inhalt

Beitrag hinzufügen

Was ist PHP?

PHP Inside

Literatur

Tutorials

PHP Manuals

Mailingliste (dt.)

FAQ (dt.)

Foren

Artikel

Links

Job-Forum

Case Studies

Mitglieder

Über diese Seiten

Interaktiv

Anzeige:
[mehr Infos]

Aktuelle Buchempfehlung

more info...

PHP Newsletter

Praxisorientiertes PHP-Wissen im und aus dem E-Business vermittelt der
Newsletter von rent-a-phpwizard.de Monat für Monat. Mehr als 1900 Menschen lesen ihn bereits. Aktuelle Ausgabe lesen?

Partner Sites

phpcrawler.de
PHP Stuff
php-homepage.de
Dynamic Web Pages
PHP Welt

Auch News/Artikel posten?

PHP auf dem Sprung zur 7 Mio. Grenze21.07.2001 - von Björn Schotte - 773 Hits - News

Wie der Website Dynamic Webpages zu entnehmen ist, hat die Verbreitung von PHP einen weiteren großen Sprung gemacht. Laut den Statistiken von Netcraft und E-Soft ist PHP nun auf mehr als 6,7 Mio. Domains installiert.
Mehr ... - 2 Kommentare

PHP@LinuxTag - Ein Rückblick20.07.2001 - von Sebastian Bergmann - 369 Hits - Veranstaltung

Georg Richter und Ulf Wendel haben die Ereignisse rund um PHP auf dem LinuxTag in einem Bericht für PHPUG.De zusammengefasst. Zusätzlich ist in Björn Schottes Newsletter auch ein Bericht über den LinuxTag verfügbar.
Mehr ... - keine Kommentare

"Openbook"-Aktion von Galileo Press19.07.2001 - von Björn Schotte - 814 Hits - Buch

Der Galileo Verlag hat heute in einer Mitteilung verlauten lassen, dass er ausgewählte Literatur zur freien Online-Lektüre zur Verfügung stellt.
Mehr ... - 1 Kommentar

Neue Runde im Streit MySQL AB vs. NuSphere19.07.2001 - von Björn Schotte - 304 Hits - News

NewsForge berichtet, dass NuSphere die Gemini Tables nun unter die GPL gestellt hat. Außerdem treffen sich Verantwortliche beider Unternehmen am morgigen Freitag, 20.07., auf neutralem Boden, um über die angespannte Situation zu reden.
Mehr ... - keine Kommentare

Streit zwischen MySQL AB und NuSphere19.07.2001 - von Björn Schotte - 313 Hits - News

NuSphere (ein kommerzielles Unternehmen, das vor kurzem PHPEd gekauft hat und MySQL-Packages mit den noch nicht unter GPL stehenden Gemini-Tables (row-level locking anstatt table-level locking) anbietet) hat vor einigen Tagen die Website mysql.org als eine nicht-kommerzielle Community-Site gelaunched und damit einen Disput zwischen den beiden Unternehmen hervorgerufen.
Mehr ... - keine Kommentare

ApacheCon Europe 2001 abgesagt18.07.2001 - von Sebastian Bergmann - 168 Hits - Veranstaltung

Wie die Apache Software Foundation am gestrigen Dienstag bekannt gab, wird die für Oktober geplante ApacheCon Europe 2001 in Dublin nicht stattfinden.
Mehr ... - keine Kommentare

[Ältere Nachrichten/Beiträge...]

TOP Event

05. - 07.11.2001
Astron Hotel, Frankfurt-Mörfelden
www.php-kongress.de

Aktuelle Jobs

freier PHP/MySQL Programmierer/-in (Hamburg)
PHP-Dozent (Dortmund)
PHP/Mysql Programmierer/inn (Kleve)
Entwickler (Berlin)
Backend Programmierer. (Wernau)

PHP Usergruppen

Die zentrale Anlaufstelle für alle deutschsprachigen PHP Usergruppen: http://www.phpug.de/.

Forum "Verschiedenes" (>> alle Foren)

Ersetzen von Trennzeichen
HEADER
alternative zur MySql abfrage!
MySQL Abfrage über Checkboxen ??
You have an error in your SQL syntax near ...
Primären DNS Server für einen Domainnamen suchen !
nur teilweise parsen
Nach geb.dat sortieren
PhpLib bzw IT(X) Templates und 2 Fragen
Datev-Dateiformat

PHP IRC Community

Die deutsch- und englischsprache PHP Community im IRC-Chat.Mehr Infos hier.

Impressum Hier werben

[PHP-DEV] Re: Proposal

2001-07-29 Thread Jeffrey A . Stuart


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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] crontab support for PHP

2001-07-29 Thread Max Landborn


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?

/Max


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12455: Srand and shuffle give odd results

2001-07-29 Thread sulka


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; $i<6; $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=12455&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12454: Static references are transient inside methods

2001-07-29 Thread nick


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=12454&edit=1


-- 
PHP Development Mailing List 
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

2001-07-29 Thread Heikki Korpela


On Sun, 29 Jul 2001, Heikki Korpela wrote:

> with mysql first in loaded modules, but crash when recode is loaded first.

I specified these the wrong way around. Sorry. :-) Recode first works ok,
mysql first doesn't.

// /

Further on the subject:

Recompile HTTPD with -ggdb2, PHP with --disable-inline-optimization,
--enable-debug, and -ggdb2. Now I get:

$ gdb httpd
GNU gdb 4.16.1
Copyright 1996 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-unknown-openbsd2.9"...
(gdb) set args -DHAVE_PHP
(gdb) run
Starting program: /usr/sbin/httpd -DHAVE_PHP

Program received signal SIGSEGV, Segmentation fault.
0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()

Uh-oh..

// /

I also forgot to send my php.ini, of course.

[PHP]

expose_php  =   Off
max_execution_time = 30
memory_limit = 8M
error_reporting =   2047
display_errors  =   Off
display_startup_errors = Off
log_errors  =   On
track_errors=   On
error_log   = /var/log/httpd/php/error.log
include_path= 
".:/usr/local/lib/php:/usr/local/lib/php/fp:/var/www/hosting/style-common"
extension_dir   =   /usr/local/lib/php/20001222
enable_dl   = On
extension=libmysql.so
extension=librecode.so
register_globals = Off
file_uploads = 0
short_open_tag = Off

-- 
<-->
  Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/


-- 
PHP Development Mailing List 
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

2001-07-29 Thread Heikki Korpela


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 
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

2001-07-29 Thread Phil Driscoll

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 
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

2001-07-29 Thread Phil Driscoll


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 
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