# Comments on PHP security - Thread: https://externals.io/message/27357 - Original archive: https://news-web.php.net/php.internals/27357 - Started by Alain Williams on 2007-01-11T14:41:44+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/27357.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #27357 — Alain Williams — 2007-01-11T14:41:44+00:00 URL: https://externals.io/message/27357#27357 This has just appeared: http://www.theregister.co.uk/2007/01/11/php_apps_security/ -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include This has just appeared: > > http://www.theregister.co.uk/2007/01/11/php_apps_security/ There are some concrete suggestions in the article that we addressed a while ago. Things like: "I'd like to see new defaults that limit include() and require() to only allow local files, thereby avoiding remote file injection." That's the default in PHP 5.2.0 which was released over 2 months ago now. "It would be nice to have a global way for a script to ignore all variables in the URL, avoiding unexpected variable manipulation and XSS forgeries." We can't really make that the default (which isn't suggested) since that would break a lot of stuff, but is has been possible to do this for years by simply removing "G" from the variables_order setting. "Maybe there's even a way to force users to filter input and escape output every time, helping to avoid SQL injection and all sorts of other common problems. That last one would go a long way." The filter extension has been available for quite a while now in pecl and is bundled with PHP 5.2 and it does exactly this. I won't disagree that we can and should do more to help people write safer apps, but we have to balance that with the ease of use that brought people to PHP in the first place along with the massive amount of existing code out there. It is an interesting balancing act. Another thing to keep in mind is that there are two very distinct security issues here. Remote vs. Local issues. Just about every reported security problem against PHP itself has been of the Local variety. That means that it is a flaw in our various attempts to separate users that share the same server in a shared hosting environment. I wrote about this back in 2004 in this note related to the PHPBB issues at the time: http://www.php.net/security-note.php Like I said there, when you share a server with someone else, you are never going to achieve 100% security against those other local users, especially if the ISP is running everyone on the same Apache instance with the same user id, etc. But even with jails/chroot there have been some interesting ways over the years to defeat those, and I don't doubt there will be more. Same goes for local PHP issues. It is very hard to protect the user from himself without completely crippling the language and the various attempts we have made over the years like safe_mode and open_basedir can never be fully secure. Something like open_basedir is however useful as one layer in a layered security model. For example, you can do an initial layer of user input filtering using something like mod_security, then further filter using the filter extension and finally use open_basedir to define a restricted set of directories that an application should be able to open files from. Any one of those 3 layers may not be 100% secure by themselves, but the chances are pretty good that in combination it would be quite hard for something nasty to get through since the holes in each would have to line up perfectly. An example would be naiive code like this: readfile("/some/path/".$_GET['filename']); Assuming the developer didn't think about input filtering at all, someone could simply put: ?filename=../../etc/passwd in the URL and they would see the local /etc/passwd file from the server. Even with shadow passwords on most systems today, it is a bad idea to allow remote users to read any file on your server. In this case you could have a mod_security rule to disallow ../.. style patterns in URLs. But if someone found a way to still sneak that pattern through, perhaps because of a bug in mod_security related to weird and wonderful character set tricks, if the application had a well-defined open_basedir setting the `readfile()` call would fail trying to read anything from /etc A second example: download Again, a very common type of mistake. Without any sort of input filtering the remote user can do something like: ?filename=/etc/passwd"onmouseover="alert(document.cookie) Here the bad guy is trying to do 2 attacks at once. It is trying to trick the download.php script into downloading /etc/passwd and it is doing a very common XSS attack. Going through our layers we might have a mod_security rule that tries to strip out tags, but in this case since there are no tags and we are simply adding an attribute to an existing tag, it might slip through. Next, ext/filter kicks in with a default filter of "special_chars" for example and changes " to " and the XSS is defeated and finally open_basedir stops the /etc/passwd access. This would all be without changing a single line of code in the obviously badly written application. Just a couple of configuration options in Apache and PHP. Of course, such default filtering and strict open_basedir settings might break the app if it is expecting unfiltered input somewhere in it or it is expecting access to a dir you haven't added to your open_basedir list, but it becomes pretty easy to identify the few places in an app where you need to loosen things a bit simply by starting off very strict and seeing where things break. I hope this explains some of our current thinking towards PHP security. I really don't think things are as bad as people make them out to be, but it is all about perception, so if they think it is bad, it is bad and we need to do a better job documenting things like the filter extension and how to apply a layered security model in PHP. -Rasmus --- ## #27359 — Stefan Esser — 2007-01-11T16:04:30+00:00 URL: https://externals.io/message/27357#27359 · In reply to: #27358 Hello Rasmus, > There are some concrete suggestions in the article that we addressed a > while ago. Things like: > > "I'd like to see new defaults that limit include() and require() to > only allow local files, thereby avoiding remote file injection." > > That's the default in PHP 5.2.0 which was released over 2 months ago now. > This is not true. It was demonstrated several times that the "protection" is easily bypassed by using data:// or php://input URLs. Maybe this is fixed in PHP 5.2.1 but it is not in 5.2.0. And it certainly is no protection at all when someone can just use one of the other URL wrappers of PHP that are considered safe and put in an overlong URL that produces a stack overflow. (Hello zip://) > Another thing to keep in mind is that there are two very distinct > security issues here. Remote vs. Local issues. Just about every > reported security problem against PHP itself has been of the Local > variety. That means that it is a flaw in our various attempts to > What a blatant lie. PHP had several bufferoverflows etc... in functions often exposed to user input and some direct remote exploits in the past. To just name a few: `htmlentities()` overflow, about a million bugs in `unserialize()`, fileupload exploits, memory_limit exploits, ... Last year there was f.e. the zend_hash_del_key_or_index vulnerability that exposed a large number of PHP applications to remote attacks. Ah yes and If I had not babysitted the CVS in the past there would be even more direct remote exploits against PHP, like the HTTP Digest Auth double free vulnerability. And yes, only looking at local holes, PHP has more than enough of them. > In this case you could have a mod_security rule to disallow ../.. style > patterns in URLs. But if someone found a way to still sneak that > pattern through, perhaps because of a bug in mod_security related to > There is nothing more trivial than sneaking something through the combination mod_security + PHP. > tag, it might slip through. Next, ext/filter kicks in with a default > filter of "special_chars" for example and changes " to " and the > Maybe, if ext/filter would be bug free... Stefan Esser PS: Stop the "We are secure" marketing and face reality --- ## #27360 — Alain Williams — 2007-01-11T16:13:20+00:00 URL: https://externals.io/message/27357#27360 > Alain Williams wrote: > > […] > > Catching typos on variable assignment doesn't really do much for > security as far as I am concerned. It causes program correctness problems, which can impact on security. One problem that I see persistently have is forgetting to declare variable 'global' in a function ... you only find out that something is wrong when the program misbehaves. Forcing variable declaration would help here. I write PHP scripts, I also occasionally teach PHP classes, so I get to see the problems that PHP newbies have. I also write & teach perl and appreciate what 'use strict' does. Would it really be that hard to add ? Ideally on a file by file basis so as to not break included stuff that isn't your own. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include Hello Rasmus, > > […] > This is not true. It was demonstrated several times that the > "protection" is easily bypassed by using data:// or php://input URLs. > Maybe this is fixed in PHP 5.2.1 but it is not in 5.2.0. And it > certainly is no protection at all when someone can just use one of the > other URL wrappers of PHP that are considered safe and put in an > overlong URL that produces a stack overflow. (Hello zip://) Yes, this has been fixed. And I didn't say it was bug free. Nothing is ever bug free, but that the feature was introduced. > > […] > What a blatant lie. PHP had several bufferoverflows etc... in functions > often exposed to user input and some direct remote exploits in the past. > To just name a few: `htmlentities()` overflow, about a million bugs in > `unserialize()`, fileupload exploits, memory_limit exploits, ... Last year > there was f.e. the zend_hash_del_key_or_index vulnerability that exposed > a large number of PHP applications to remote attacks. Ah yes and If I > had not babysitted the CVS in the past there would be even more direct > remote exploits against PHP, like the HTTP Digest Auth double free > vulnerability. And yes, only looking at local holes, PHP has more than > enough of them. Sure, but the majority were still local. Some of the local ones can of course be triggered remotely given the right circumstances which is why they are still very important to fix. We fix them as fast as we can and appreciate any help we get from you and others on this front. > PS: Stop the "We are secure" marketing and face reality This isn't "we are secure" marketing. This is simply explaining what we are doing to make PHP more secure. -Rasmus --- ## #27362 — Pierre — 2007-01-11T16:14:06+00:00 URL: https://externals.io/message/27357#27362 · In reply to: #27359 Hello Stefan, > Hello Rasmus, > > […] > This is not true. It was demonstrated several times that the > "protection" is easily bypassed by using data:// or php://input URLs. > Maybe this is fixed in PHP 5.2.1 but it is not in 5.2.0. And it > certainly is no protection at all when someone can just use one of the > other URL wrappers of PHP that are considered safe and put in an > overlong URL that produces a stack overflow. (Hello zip://) For your information, zip is not enabled by default. If you have a bug/issue about the specific zip:// URL, please let me know. Ilia and Tony already fixed some paths fixes and the fixes are available in zip-1.8.4. They will be in 5.2.1. --Pierre --- ## #27363 — Alain Williams — 2007-01-11T16:17:31+00:00 URL: https://externals.io/message/27357#27363 · In reply to: #27359 > PS: Stop the "We are secure" marketing and face reality More to the point: ''We might be secure because we are careful experienced programmers'', however many of those who write in PHP are not careful and/or experienced, we should be looking to help those people - there are more of them than they are of us. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include For your information, zip is not enabled by default. If you have a > bug/issue about the specific zip:// URL, please let me know. Ilia and > Tony already fixed some paths fixes and the fixes are available in > zip-1.8.4. They will be in 5.2.1. For your information Pierre: Security Bugs in PHP are usually found by me. So guess twice WHO told security@php.net that there are bufferoverflows in zip:// URLs and WHY there have been bugfixes to ext/zip. BTW: Last time I checked, popular packages like dotdeb PHP activate ext/zip by default... And yes... Also prepare for the ***more than 30 vulnerabilities*** I disclosed to security@php.net during the last 3 weeks. Have fun... Stefan --- ## #27365 — Mark Krenz — 2007-01-11T16:25:45+00:00 URL: https://externals.io/message/27357#27365 · In reply to: #27363 On Thu, Jan 11, 2007 at 04:17:31PM GMT, Alain Williams [addw@phcomp.co.uk] said the following: > > > > […] > > More to the point: ''We might be secure because we are careful experienced programmers'', > however many of those who write in PHP are not careful and/or experienced, we should > be looking to help those people - there are more of them than they are of us. > And for the programmers that write programs that require safe mode to be off or don't provide a provision for having it on. STOP telling your users things like "If your webhost has safe mode on then they suck". Safe mode is the only way to get around certain situations. Get a clue. You know who you are. Somehow I doubt any of these said programmers are on this list. Shame. Mark -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ --- ## #27366 — Pierre — 2007-01-11T16:27:33+00:00 URL: https://externals.io/message/27357#27366 · In reply to: #27364 Hi Stefan, > > > […] > For your information Pierre: Security Bugs in PHP are usually found by > me. So guess twice WHO told security@php.net that there are > bufferoverflows in zip:// URLs and WHY there have been bugfixes to ext/zip. No idea who posted them or if someone posted something about zip. As you know I have no access to security@ and so far all I see are commits in my packages without much explanations. Not like I do not want you or anyone else to help or to do not give you the credits. But I did not know that someone else reported the issues, I apologize for that. > BTW: Last time I checked, popular packages like dotdeb PHP activate > ext/zip by default... > > And yes... Also prepare for the ***more than 30 vulnerabilities*** I > disclosed to security@php.net during the last 3 weeks. Nice, better later than never. Remember my numerous requests in the last months *BEFORE* the stable release (and you were still a PHP Securtiy member)? > Have fun... I have fun anyway, if not I will not bother to discuss that here. --Pierre --- ## #27367 — Christian Schneider — 2007-01-11T16:38:58+00:00 URL: https://externals.io/message/27357#27367 · In reply to: #27360 Alain Williams wrote: > One problem that I see persistently have is forgetting to declare variable 'global' > in a function ... you only find out that something is wrong when the program > misbehaves. Forcing variable declaration would help here. a) You should never use 'global' under normal circumstances. The very few occasions where you really, really need a global variable it should be painful and done with $GLOBALS IMHO. Mentioning 'global' and 'teaching PHP' in the same posting makes me shiver ;-) b) Use `E_NOTICE` if you are want PHP baby-sitting you by complaining about undefined variables. Using undefined variables is a key feature for me so I won't use `E_NOTICE` (in an unpatched form ;-)) but if you insist: The option is there. - Chris --- ## #27368 — Alain Williams — 2007-01-11T16:45:17+00:00 URL: https://externals.io/message/27357#27368 · In reply to: #27367 > Alain Williams wrote: > > […] > > a) You should never use 'global' under normal circumstances. The very > few occasions where you really, really need a global variable it should > be painful and done with $GLOBALS IMHO. Mentioning 'global' and > 'teaching PHP' in the same posting makes me shiver ;-) > b) Use `E_NOTICE` if you are want PHP baby-sitting you by complaining > about undefined variables. Using undefined variables is a key feature > for me so I won't use `E_NOTICE` (in an unpatched form ;-)) but if you > insist: The option is there. No. `E_NOTICE` will tell you if you *use* an undefined variable, it won't tell you anything if you assign to a typeo. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include On Thu, Jan 11, 2007 at 04:17:31PM GMT, Alain Williams > [addw@phcomp.co.uk] said the following: > > […] > > And for the programmers that write programs that require safe mode to > be off or don't provide a provision for having it on. STOP telling > your > users things like "If your webhost has safe mode on then they suck". > Safe mode is the only way to get around certain situations. Get a > clue. > You know who you are. > > Somehow I doubt any of these said programmers are on this list. > Shame. > > Mark > > > -- > Mark S. Krenz > IT Director > Suso Technology Services, Inc. > http://suso.org/ > > -- > > > Ilia Alshanetsky --- ## #27370 — Ilia Alshanetsky — 2007-01-11T17:05:45+00:00 URL: https://externals.io/message/27357#27370 · In reply to: #27357 > This has just appeared: > > http://www.theregister.co.uk/2007/01/11/php_apps_security/ Of many people who use PHP not many have strong programming background and even fewer experience with security. The use PHP because it makes it easy to solve problems, especially in a web environment. When you consider this it is hardly surprising that many people write bad and/or insecure code. While PHP does try to make things better, and occasionally has bugs in the language core you need to realize that PHP is a programming language. As such if you really want to shoot yourself in the foot you can, just as you can do with C/C++/Perl/Python/etc... Ilia Alshanetsky --- ## #27371 — Alain Williams — 2007-01-11T17:11:52+00:00 URL: https://externals.io/message/27357#27371 · In reply to: #27370 > > > > > […] > > Of many people who use PHP not many have strong programming > background and even fewer experience with security. The use PHP > because it makes it easy to solve problems, especially in a web > environment. When you consider this it is hardly surprising that many > people write bad and/or insecure code. While PHP does try to make > things better, and occasionally has bugs in the language core you > need to realize that PHP is a programming language. As such if you > really want to shoot yourself in the foot you can, just as you can do > with C/C++/Perl/Python/etc... I think that everyone would agree with that. The discussion is how PHP can help them to discover problems in their scripts. This is what led to Wietse Venema's suggestion about tainting a few weeks ago. These may be things that members of this forum do not feel that they need, but the ''quality'' of the majority of PHP programmers is such that they would be of benefit. To an extent it is an accolade to PHP that novice/... programmers can use it do create applications, it just puts a greater burden on us to do what we can to protect them from their own problems. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include The discussion is how PHP can help them to discover problems in their > scripts. This is what led to Wietse Venema's suggestion about tainting > a few weeks ago. These may be things that members of this forum do not > feel that they need, but the ''quality'' of the majority of PHP > programmers is such that they would be of benefit. > > To an extent it is an accolade to PHP that novice/... programmers can > use it do create applications, it just puts a greater burden on us > to do > what we can to protect them from their own problems. The tools already exist, look at `E_NOTICE` for example. A good number of PHP exploits are caused by register_globals + un-initialized vars. If the developers of those apps tried to run their code with that error reporting method enabled there would be far fewer security bugs all around. Ilia Alshanetsky --- ## #27373 — Alain Williams — 2007-01-11T17:29:42+00:00 URL: https://externals.io/message/27357#27373 · In reply to: #27372 > > > > […] > > The tools already exist, look at `E_NOTICE` for example. A good number > of PHP exploits are caused by register_globals + un-initialized vars. > If the developers of those apps tried to run their code with that > error reporting method enabled there would be far fewer security bugs > all around. `E_NOTICE` flags up attempts to use an uninitialised variable, it is not helpful if you assign to a typeo. This people do and can be hard to find, especially if it is not in an often used code path. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include > > […] > > `E_NOTICE` flags up attempts to use an uninitialised variable, it is not > helpful if you assign to a typeo. This people do and can be hard to find, > especially if it is not in an often used code path. That is why there is a concept called "testing" [1] and code coverage [2]. [1]. http://phpunit.de/ [2]. http://sebastian-bergmann.de/archives/578-Code-Coverage-Reports-with-PHPUnit-3.html regards, Derick --- ## #27375 — Alain Williams — 2007-01-11T17:53:17+00:00 URL: https://externals.io/message/27357#27375 · In reply to: #27374 > That is why there is a concept called "testing" [1] and code coverage > [2]. > > [1]. http://phpunit.de/ > [2]. http://sebastian-bergmann.de/archives/578-Code-Coverage-Reports-with-PHPUnit-3.html You are an experienced and careful programmer, that is why you understand the value of doing this sort of thing. The trouble is that most PHP programers are not experienced and/or careful ... that is *why* many PHP scripts have nasty bugs in them. As I said: we are looking at ways of helping the sort of person who would not come near this mail list. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include > > > […] > > You are an experienced and careful programmer, that is why you > understand the value > of doing this sort of thing. The trouble is that most PHP > programers are > not experienced and/or careful ... that is *why* many PHP scripts > have nasty bugs in > them. > > As I said: we are looking at ways of helping the sort of person who > would not > come near this mail list. Uhm those are PHP tools for PHP code, what do they have to do with internals. Rather then whining about "if I only had tool XYZ" use what's already widely available. Ilia Alshanetsky --- ## #27377 — Stanislav Malyshev — 2007-01-11T18:14:12+00:00 URL: https://externals.io/message/27357#27377 · In reply to: #27359 > PS: Stop the "We are secure" marketing and face reality I wonder what do you mean by that - that PHP group should publish press release "PHP is not secure, please do not use it anymore" or what? I see PHP group is working quite well eliminating the security issues. As far as I know, last year there was 7 remotely exploitable issues in PHP (which is regrettable but that's the way of life to have bugs), and all of them are fixed, IIRC, and within acceptable timeframe (the last can be debatable, but PHP being opesource project the only way to fix it is to get more participation from people in submitting patches). I know of no remotely exploitable security issue that is now in current PHP version. So I wonder what would you like PHP Group to improve? What would you mean by facing reality - what in your opinion the reality is and what would you have PHP group to do to satisfy you on facing reality account? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #27378 — Stefan Esser — 2007-01-11T18:59:43+00:00 URL: https://externals.io/message/27357#27378 · In reply to: #27377 > I wonder what do you mean by that - that PHP group should publish > press release "PHP is not secure, please do not use it anymore" or > what? I see PHP group is working quite well eliminating the security > issues. As far as I know, last year there was 7 remotely exploitable > issues in PHP (which is regrettable but that's the way of life to have > bugs), and all of them are fixed, IIRC, and within acceptable > timeframe (the last can be debatable, but PHP being opesource project > the only way to fix it is to get more participation from people in > submitting patches). I know of no remotely exploitable security issue > that is now in current PHP version. > So I wonder what would you like PHP Group to improve? What would you > mean by facing reality - what in your opinion the reality is and what > would you have PHP group to do to satisfy you on facing reality account? First of all PHP group is doing nothing. Neither do they improve PHP's security nor do they stop well known PHP license abusers (because they are friends). Secondly security patches are done by Ilia and maybe the Zend stuff by Dmitry. All the others are doing nothing in the sense of security. And do I need to remind you about a certain bug in the new super duper Zend Memory manager that results in a far too small buffer being allocated? Do I need to post an exploit that uses this bug to exploit for example the Soap HTTP client from ext/soap? This is a kind of remote exploit against PHP. And god knows how many other places are vulnerable because of the new "improved" Zend Memory Manager. And what about the heap underflow bug in ext/filter... Also not a remote exploit? The fact that you do not know about any remote exploit against PHP is quite irrelevant for reality. Stefan Esser --- ## #27379 — Jordan Moore — 2007-01-11T19:23:19+00:00 URL: https://externals.io/message/27357#27379 · In reply to: #27378 This is pathetic. I thought most of you were adults, but I really can't tell sometimes. Why can't this be discussed without everyone getting upset and snapping at each other? The biggest problem with PHP right now is how thick-headed and cocky some of the posters to this list are. Grow up, and then maybe PHP will have a chance to grow up. It's only taken a couple months to realize how much time is wasted on political crap on this list instead of bug-fixing. > > > […] > First of all PHP group is doing nothing. Neither do they improve PHP's > security nor do they stop well known PHP license abusers (because they > are friends). > Secondly security patches are done by Ilia and maybe the Zend stuff by > Dmitry. All the others are doing nothing in the sense of security. > > And do I need to remind you about a certain bug in the new super duper > Zend Memory manager that results in a far too small buffer being allocated? > > Do I need to post an exploit that uses this bug to exploit for example > the Soap HTTP client from ext/soap? This is a kind of remote exploit > against PHP. And god knows how many other places are vulnerable because > of the new "improved" Zend Memory Manager. > > And what about the heap underflow bug in ext/filter... Also not a remote > exploit? > > The fact that you do not know about any remote exploit against PHP is > quite irrelevant for reality. > > Stefan Esser --- ## #27380 — Ilia Alshanetsky — 2007-01-11T19:29:32+00:00 URL: https://externals.io/message/27357#27380 · In reply to: #27379 Rather then commenting on what other people should and should not do, do something productive like fix bugs or help to extend the PHP test suit. > This is pathetic. I thought most of you were adults, but I really > can't tell sometimes. > > Why can't this be discussed without everyone getting upset and > snapping at each other? The biggest problem with PHP right now is how > thick-headed and cocky some of the posters to this list are. Grow up, > and then maybe PHP will have a chance to grow up. > > It's only taken a couple months to realize how much time is wasted on > political crap on this list instead of bug-fixing. > > > > […] > > -- > > > Ilia Alshanetsky --- ## #27381 — Jordan Moore — 2007-01-11T19:35:13+00:00 URL: https://externals.io/message/27357#27381 · In reply to: #27380 That was my intent when I joined the list. I wanted to get a feel for the community and the development process. This is the first open-source project that I've considered contributing to, so it's all new to me. I still plan to dive into it, but it's disheartening to see some of these petty arguments. That is all... Jordan > Rather then commenting on what other people should and should not do, > do something productive like fix bugs or help to extend the PHP test > suit. > > > > > […] > > Ilia Alshanetsky > > > > > -- Jordan Moore - Creative Director Sanctus Studios LLC http://sanctusstudios.com (360) 616-4818 --- Next page: https://externals.io/message/27357.md?page=2