Re: [PHP-DEV] Bug #12842 Updated: TSRM/tsrm_virtual_cwd.c:568:`mode_t' is promoted to `int'
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=stdargapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=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 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] use indent instead of fixing whitespace by hand?
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 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] Engine 2
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:
?php
function func1($object) {
$object-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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: compile fails on html.c (CODESET undeclared)
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 http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
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 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
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] Bug #12335 Updated: mail() function returns false butthe email was sent.
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 #12455 Updated: Srand and shuffle give odd results
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] [PHP] mail() help (fwd)
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] Proposal
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] Bug #12450: Segfaults if recode is loaded after mysqlor imap
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] Security Issues
On Sat, 28 Jul 2001, Zeev Suraski wrote:
Anyway, to be more constructive - Andi had an idea when we were catching a
cab earlier today (yesterday). His idea (which I'm just pitching, we
haven't thought this through at all yet) is that instead of having
register_globals on, or off, we would have it as unset, by default. When
unset (i.e., on new installations) - PHP will not run, but instead display
information about register_globals, its security implications, examples,
and a general recommendation to turn it off if at all possible.
I think one issue here is that people are so used to using certain
kind of language syntax that they're simply overestimating the effort
of typing $_{GET,POST}['foo'] when needed. With some time to
get used to it, I think most of the people will see why this is a good
idea. Your idea sounds like something that might help with this.
One thing that would further this cause would be to explain how to
start converting your existing codebase to be more secure in
small chunks.
I have no experience with other web servers than Apache, but with
Apache I use for my own homepages a .htaccess similar to the one
below. I have similar settings for many virtual hosts and directories
in the server configuration files.
# Security
php_flag register_globals Off
# Error tracking / displaying / logging
php_value error_reporting 2047
php_flag display_errors Off
php_flag log_errors On
php_value error_log 'REPLACE_ME'
php_flag track_errors On
Zeev
--
--
Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
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
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]
Re: [PHP-DEV] Security Issues
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=mktempsektion=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]
