Re: [PHP-DEV] Bug #12842 Updated: TSRM/tsrm_virtual_cwd.c:568:`mode_t' is promoted to `int'

[Heikki Korpela]

On 22 Aug 2001 [EMAIL PROTECTED] wrote:

> reproduced by [EMAIL PROTECTED] (bug report #11761.

> tsrm_virtual_cwd.c:568: `mode_t' is promoted to `int' when passed through `...'
> tsrm_virtual_cwd.c:568: (so you should pass `int' not `mode_t' to `va_arg')

See:

a recently updated stdarg(3) manual page:


http://www.openbsd.org/cgi-bin/man.cgi?query=stdarg&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

discussion on the gcc list on the matter:

http://gcc.gnu.org/ml/gcc-patches/1999-09/msg00221.html

The same problem was iirc present on OpenBSD. Problem is that mode_t is
a primitive system data type that may be defined as a short or an int
(in theory I think that POSIX even allows a float), depending on
the system; same goes for other such data types, of course.

Unfortunately, I do not have edit access for the bug so I have to
send this to the list directly. Sorry.



-- 
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] use indent instead of fixing whitespace "by hand"?

[Heikki Korpela]

On Mon, 13 Aug 2001, Jani Taskinen wrote:

> Hehe..last time I tried indent with PHP c-sources they made it segfault.
> --Jani

Hey people, did you remember there are other options than (g)indent
out there?

http://www.iua.upf.es/~mdeboer/astyle_on_commit/



-- 
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] Engine 2

[Heikki Korpela]

On Fri, 10 Aug 2001, Andi Gutmans wrote:

> I'm also
> interested in how many scripts are actually broken by the fact that objects
> are not copied when sent to functions by value and so on.

Did I get this right:

foo = 'bar';
}

function func2() {
$object = new StdClass;
$object->foo = 'not bar';
func1($object);
echo $object->foo;
}
func2();
?>

After the engine change, the above would print 'bar'?



-- 
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: compile fails on html.c (CODESET undeclared)

[Heikki Korpela]

On Wed, 8 Aug 2001, Wez Furlong wrote:

> Err, that's a little odd.
> I would expect your system to have all of the things required for that
> to work.
> What does the config.log say about HAVE_LOCALE_H and HAVE_LANGINFO_H?

> I suspect this can be fixed by changing line 231 to be
> #if HAVE_LANGINFO_H && HAVE_LOCALE_H && defined(CODESET)

Please do, it's repeatable on OpenBSD-current; I haven't reported it because
I didn't have a fix yet at the time and I've been busy since.

We have langinfo.h, but no CODESET is defined.


-- 
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: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Heikki Korpela]

On 7 Aug 2001, Stig Sæther Bakken wrote:

> > If there were a thousand extensions, we may have to rethink it - but
> > the good solution would probably be JIT initialization.
> Now we're talking!  I assume it is not straightforward, what are the
> technical challenges in doing JIT module initialization?

Is it just my imagination, or can anyone say for sure if we'll even have
shared libraries by the time someone's trying to load a thousand
extensions at once? :-)


-- 
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 #12335 Updated: mail() function returns false butthe email was sent.

[Heikki Korpela]

On 1 Aug 2001 [EMAIL PROTECTED] wrote:

> #if definded (EX_TEMPFAIL)

There's a typo. :-)

> So what could be the problem with EX_OK and EX_TEMPFAIL that the same if query is 
>working in 4.0.4pl1 and not
> in 4.0.6? Who is EX_OK and EX_TEMPFAIL defined?

>From my sysexits(3):

 EX_TEMPFAIL (75)  Temporary failure, indicating something that is not
   really an error.  In sendmail, this means that a
   mailer (e.g.) could not create a connection, and
   the request should be reattempted later.

Check your qmail logs.

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #12505: array_sum function total calculate error

[Heikki Korpela]

On 1 Aug 2001 [EMAIL PROTECTED] wrote:

> From: [EMAIL PROTECTED]
> Operating system: Red Hat Linux 7.1
> PHP version:  4.0.4pl1
> PHP Bug Type: Arrays related
> Bug description:  array_sum function total calculate error
> $tt=array(382478633,367687181,452504275,471367521,848270658,1181944543);
> $total_tt=array_sum($tt);
> echo "Total_tt=".$total_tt;
> // Prints  Total_tt=-590714485
> Must be 3704252811.

Confirmed on:

i386 / OpenBSD-current / PHP 4.0.6 (from OpenBSD ports tree)
i386 / RH 7.1 / PHP 4.0.5  (from RH Rawhide)
i386 / RH 7.0 / PHP 4.0.5  (from Arvin's 4.0.5 RPMS)

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [PHP] mail() help (fwd)

[Heikki Korpela]

On Wed, 1 Aug 2001, Jani Taskinen wrote:

> I think this is good. If some resource isn't available, then the function
> using the resource shouldn't be enabled either. So the correct fix would
> be to add a error message to mail() function, IMO.
> --Jani

The fact that the machine that PHP is compiled on doesn't have a
specific binary often has nothing to do with:

1) what the machine PHP will be *run on* will include
2) what sort of binaries the machine will have tomorrow

A sensible default should be provided, regardless of whether or not
you can set it in php.ini.

As for bumping a warning when sendmail_path is null in php_mail -
that sounds like a good idea. How's this look like?

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

===
RCS file: /repository/php4/ext/standard/mail.c,v
retrieving revision 1.41
diff -u -IExp -b -B -p -r1.41 mail.c
--- mail.c  30 Jul 2001 06:18:06 -  1.41
+++ mail.c  1 Aug 2001 05:05:02 -
@@ -154,6 +154,7 @@ PHPAPI int php_mail(char *to, char *subj
}
return 1;
 #else
+   php_error(E_WARNING, "Your sendmail_path is null - cannot send mail! 
+Check php.ini");
return 0;
 #endif
}
@@ -192,6 +193,7 @@ PHPAPI int php_mail(char *to, char *subj
 #endif
 #endif
{
+   php_error(E_WARNING, "Mail delivery program returned with exit 
+code: %d", ret);
return 0;
} else {
return 1;


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Heikki Korpela]

On 31 Jul 2001 [EMAIL PROTECTED] wrote:

> Then load the load100times.php in your browser. The result
> should be 100 but is still 4 on the machines I'm testing
> on.

It works fine here. (4.0.6 on OpenBSD 2.9-current.)

Maybe your system's random functions are broken. Which random
function does your php_rand() call anyway?

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #12450: Segfaults if recode is loaded after mysqlor imap

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

Re: [PHP-DEV] Bug #12450: Segfaults if recode is loaded after mysqlor imap

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

Re: [PHP-DEV] Proposal

[Heikki Korpela]

On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:

>  // And perhaps some globbing:
>  // Import any variable with abc in its name from anywhere.
>  // Could alternatively use SQL-style or perhaps real regex
>  // expressions here although I think full regex support would be
>  // slightly overkill and perhaps too confusing for people.
>  import_globals("GPCES","*abc*");

This sounds brilliant.

Would something glob(3)bish be a bad idea? I could imagine that

1) more people are familiar with it than with regexs
2) it'd be easier to grasp in the first place

> -Rasmus

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Heikki Korpela]

On Sat, 28 Jul 2001, Zeev Suraski wrote:

> BTW, I'm just being argumentative here.  I personally think that having
> E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean.  A
> great deal of PHP programmers will not agree with me, though, so I haven't
> made up my mind on whether I support changing this default or not.

Consider it this way:

If an user decides to use my library that is E_NOTICE clean and
doesn't have E_NOTICE, what happens?

If I decide to use a library that isn't E_NOTICE clean and I have
E_NOTICE, what happens?

The main issue here from my point of view is interoperation and
distribution of software.

> 2.  PHP, with register_globals=on, mixes information coming from the user
> with information coming from code written by the developer, to a degree
> where it's impossible to differentiate between the two.  Given problem #1,
> this often leads to security problems.

As long as we have a small quantity of small programs and libraries
with minor distribution, the maintainance effort of obfuscated code
is not vast, and thus flexibility may be default, and perhaps the
primary aim.

As software written in PHP grows in popularity and the codebase itself
grows in size, maintainance becomes harder. Thus I think that a clear
message from the developers - whether it's E_NOTICE or register_globals
or an open letter called "Code Together" - that states "we are
concerned that it's becoming increasingly hard to incorporate large
codebases together without compromising stability and security" is
in my opinion in place.

But that's of course only me.

> Zeev

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Heikki Korpela]

On Sat, 28 Jul 2001, Zeev Suraski wrote:

> Anyway, to be more constructive - Andi had an idea when we were catching a
> cab earlier today (yesterday).  His idea (which I'm just pitching, we
> haven't thought this through at all yet) is that instead of having
> register_globals on, or off, we would have it as unset, by default.  When
> unset (i.e., on new installations) - PHP will not run, but instead display
> information about register_globals, its security implications, examples,
> and a general recommendation to turn it off if at all possible.

I think one issue here is that people are so used to using certain
kind of language syntax that they're simply overestimating the effort
of typing $_{GET,POST}['foo'] when needed. With some time to
get used to it, I think most of the people will see why this is a good
idea. Your idea sounds like something that might help with this.

One thing that would further this cause would be to explain how to
start converting your existing codebase to be more secure in
small chunks.

I have no experience with other web servers than Apache, but with
Apache I use for my own homepages a .htaccess similar to the one
below. I have similar settings for many virtual hosts and directories
in the server configuration files.

# Security
php_flag  register_globals Off

# Error tracking / displaying / logging
php_value error_reporting 2047
php_flag  display_errors Off
php_flag  log_errors On
php_value error_log ''
php_flag  track_errors On

> Zeev

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Heikki Korpela]

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 could do is hand him the gun safely
> pointed in the other direction, and not point it to his brain.

We know that tricks and complications don't make anything more
secure - quite the contrary, they make the applications more
bug-prone.

We also know that good programming practices and routines help avoid
bugs. Alone, they won't help, but a person who is adviced or even
enforced to apply those practices will usually wonder: "huh, why
shouldn't I use tempnam or gets? Hmm, maybe I'll read the manual
page...". Indirectly, this also leads to changes in attitude as
the programmer starts to realize that the threats he or she is
being warned of are real and not mere paranoia of people encrypting
their swap.

The question here is whether or not register_globals is a trick
or a way to advise people of better practices.

Would anyone like to show me the design that gets innecessarily
('innecessary' meaning 'if the application wasn't well designed
in the first place, it's obvious it should be changed') complicated
when you enforce E_NOTICE and register_globals?

//

Everyone's emphasizing documentation on security concerns. What would
be the first things I'd like to see (or do) tre he possible security
implications for function calls or language structures in the reference
manual, next to their corresponding references. See, for example,
the bugs section of one implementation of the manual page for
mktemp(3):

http://www.openbsd.org/cgi-bin/man.cgi?query=mktemp&sektion=3

Yes, sure it would be nice if there was a guide to secure programming
in PHP. Oh, but wait... I think there are some; but people don't
necessarily read them. They think that security issues don't concern
them.

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Heikki Korpela]

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 an internal variable to something.
> I have...  And quite a lot use isset(), which is much more common and
> popular than empty().

I use both isset() and empty() in hundreds of lines of code that check
my own internally defined structures, such as predefined arrays that define
behaviour of the code.

> 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 register_globals to off (probably less, but not that much
> less).

One major problem I'm currently having is that I like to reuse
other people's PHP code if any is available, and I have to hack up
a horrible number of directory- and virtual host-specific error_reporting
values because the code otherwise generates megabytes of log over a very
short while.

This makes it extremely hard to maintain a codebase that uses both
our own and others' code where our code is strictly developed against
E_NOTICE and others' will have to either be reviewed thoroughly or
constrained in a shell where different rules apply.

I've been told that E_NOTICE generates warnings that you would have
to bypass by making things more complicately and that this would
hurt one of the greatest advantages of the language: flexibility.
This does, of course, hold some truth, but I think that time and
experience has shown that this specific flexibility (E_NOTICE and
register_globals) causes too much damage and has too many security
implications to be left as is. Unexperienced programmers should be
given defaults that guide them in a right direction with good
programming practices, and leave the advanced flexibility options to
more experienced programmers.

> No doubt, this would cause many
> (perhaps even most) PHP applications out there not to install out of the
> box, but I think that setting register_globals off is a pretty pressing
> matter, and without some pain (i.e., forcing app authors to update their
> apps to work with the track_vars arrays) we won't get anywhere.

Maintaining backward compatibility at all costs has made Perl what it
is today. I've been happy that PHP has this far not taken this matter
to such limits.

> Zeev

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]