Re: [PHP-DEV] Re: [PHP-QA] run-tests.php
Hi Nuno, On Thu, 2007-09-13 at 20:20 +0100, Nuno Lopes wrote: > >> now i get the issue. It grabbs more than one line! This means > >> run-tests.php has to be fixed. The whole thing is designed under > >> the assumption that %s catches no new lines and hence only one > >> line. > > > > That would be the best answer but I think it's a difficult fix and > > whatever it was might break other tests. I think it would mean replacing > > %s with something other than .+?. I'll have a look tomorrow and see if I > > can find a regex that would do - one of the things that had me confused > > for a while was that I thought the ? (non-greedy qualifier) should > > guarentee the minimum match but it doesn't work quite like that. > > > OK, so basically it is impossible to fix the current regex to match what we > want (I had a quick chat with the PCRE author and he thinks the same). > I propose the following patch: > http://web.ist.utl.pt/nuno.lopes/php_run_tests_%s.txt Should be http://web.ist.utl.pt/nuno.lopes/php_run_tests_%25s.txt I guess ;-) > The main changes are: > '%s' => '[^\r\n]+' > '%a' => '.+' > > This means that some tests have to be fixed, but the majority passes. Most > important is that with this patch I found some tests that had the expected > output wrong. > > So unless someone rejects this patch, I'll commit it (and update the > http://qa.php.net/write-test.php page too). > Anyway, I don't think that a function name should be replaced by %s. The > expected output should be as stricter as possible. from a short review of the patch I think it's fine and a good idea. So please go on and commit. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: mert
Translating the documentation -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] run-tests.php
now i get the issue. It grabbs more than one line! This means run-tests.php has to be fixed. The whole thing is designed under the assumption that %s catches no new lines and hence only one line. That would be the best answer but I think it's a difficult fix and whatever it was might break other tests. I think it would mean replacing %s with something other than .+?. I'll have a look tomorrow and see if I can find a regex that would do - one of the things that had me confused for a while was that I thought the ? (non-greedy qualifier) should guarentee the minimum match but it doesn't work quite like that. OK, so basically it is impossible to fix the current regex to match what we want (I had a quick chat with the PCRE author and he thinks the same). I propose the following patch: http://web.ist.utl.pt/nuno.lopes/php_run_tests_%s.txt The main changes are: '%s' => '[^\r\n]+' '%a' => '.+' This means that some tests have to be fixed, but the majority passes. Most important is that with this patch I found some tests that had the expected output wrong. So unless someone rejects this patch, I'll commit it (and update the http://qa.php.net/write-test.php page too). Anyway, I don't think that a function name should be replaced by %s. The expected output should be as stricter as possible. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RE : RE : Namespaces and __autoload()
Are you sure we would need to create a new hook ? If the existing autoload handlers receive a request for a function, they search for a class with that name. Apart from a waste of time, it is harmless. We can even have BC : you just have to declare your autoload handler with an optional second argument, whose default value is 'class'. This would allow new autoload handlers to run on previous PHP versions. Well, that might be an option too, but let's cross that bridge when we come to it :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] array_get()
Hello Andrew,
if we go the array_get() route as a short half solution to hopefully make
a lot of people happy (at least it would serve $_GET/_REQUEST etc needs).
Then I think we should make it a bit more useable:
Get the default or the multilevel subscription of $ar
proto mixed array_get(array $ar, mixed index*, mixed $default)
function array_get(array $ar) {
$ret = $ar;
for ($i=1; $i < func_num_args() - 1; ++$i) {
$idx = func_get_arg($i);
if (array_key_exists($idx, $ret)) {
$ret = $ret[$idx];
} else {
if (func_num_args() > 1) {
return func_get_arg(func_num_args() - 1);
} else {
return NULL;
}
}
}
return $ret;
}
best regards
marcus
Thursday, September 13, 2007, 2:54:51 PM, you wrote:
> On Sep 12, 2007, at 2:25 PM, Lukas Kahwe Smith wrote:
>> Andrew Shearer wrote:
>>
>>> Meanwhile, array_get() provides the most-needed functionality
>>> while avoiding
>>> the issues that prevented ifsetor's acceptance.
>>
>> Aside from lack of BC hacks what is the issue? I remember some
>> fussing about the name, but I find this a joke of an argument. You
>> cant get much clearer a name than ifsetor().
>>
>>> There's a backward compatibility problem with ifsetor: its special
>>> syntax
>>> means that there's no way to write a pure-PHP userland version of
>>> it. The
>>> effect is that there's no upgrade path for applications that have to
>>> straddle both old and new versions of PHP, and practical
>>> usefulness of
>>> ifsetor would be delayed for years after release.
>>
>>
>> I use ifsetor() type functionality on a daily basis. As such I
>> would appreciate it if it would be an operator and would make its
>> way not only into php 6, but also php 5.3.
>>
>> Marcus's half solution is not a solution to what I need. Andrew's
>> solution gets close enough to solve my real world needs. Now if I
>> could just see the slightest bit if a real argument against ifsetor
>> (), I might even vote for array_get() (not sure if I appreciate the
>> name though).
>>
>> regards,
>> Lukas
> I think we want the same thing. We both want the essential
> functionality in PHP one way or another. If ifsetor was in the
> running now, I'd support it. But after seeing the discussion and lack
> of consensus on it since 2004, I'm sure that the best way to reach
> the goal is to champion array_get().
> Other suggestions for the name are welcome, but the choice of it was
> careful. array_get() has at least one precendent, the Python dict.get
> () method, which works basically the same way. The fact that the same
> name and function signature (give or take a reference) was also
> suggested completely independently in a PHP wishlist item means it's
> probably on the right track.
> --
> Andrew Shearer
> http://ashearer.com/
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] array_get()
On 9/13/07, Peter Brodersen <[EMAIL PROTECTED]> wrote: > I'm not too fond of a function that begins with if* - it might > misdirect people to think it's a control structure. ifsetor was not a function (like isset). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] array_get()
Hi, On Wed, 12 Sep 2007 20:25:39 +0200, in php.internals [EMAIL PROTECTED] (Lukas Kahwe Smith) wrote: >Aside from lack of BC hacks what is the issue? I remember some fussing >about the name, but I find this a joke of an argument. You cant get much >clearer a name than ifsetor(). just my opinion on the color of the bike shed: Maybe a function named like coalesce() as known from SQL. Although an unset variable yields NULL, this is not the same as testing whether the variable is actually set or not. But still, if it would return the first non-null value then it might be good in conjunction with user input. I'm not too fond of a function that begins with if* - it might misdirect people to think it's a control structure. (and now back to your original programme) -- - Peter Brodersen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] array_get()
On Sep 12, 2007, at 2:25 PM, Lukas Kahwe Smith wrote: Andrew Shearer wrote: Meanwhile, array_get() provides the most-needed functionality while avoiding the issues that prevented ifsetor's acceptance. Aside from lack of BC hacks what is the issue? I remember some fussing about the name, but I find this a joke of an argument. You cant get much clearer a name than ifsetor(). There's a backward compatibility problem with ifsetor: its special syntax means that there's no way to write a pure-PHP userland version of it. The effect is that there's no upgrade path for applications that have to straddle both old and new versions of PHP, and practical usefulness of ifsetor would be delayed for years after release. I use ifsetor() type functionality on a daily basis. As such I would appreciate it if it would be an operator and would make its way not only into php 6, but also php 5.3. Marcus's half solution is not a solution to what I need. Andrew's solution gets close enough to solve my real world needs. Now if I could just see the slightest bit if a real argument against ifsetor (), I might even vote for array_get() (not sure if I appreciate the name though). regards, Lukas I think we want the same thing. We both want the essential functionality in PHP one way or another. If ifsetor was in the running now, I'd support it. But after seeing the discussion and lack of consensus on it since 2004, I'm sure that the best way to reach the goal is to champion array_get(). Other suggestions for the name are welcome, but the choice of it was careful. array_get() has at least one precendent, the Python dict.get () method, which works basically the same way. The fact that the same name and function signature (give or take a reference) was also suggested completely independently in a PHP wishlist item means it's probably on the right track. -- Andrew Shearer http://ashearer.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] So called exploitable code found in UseBB 1 by Ilia
Hello all, Since this is the first time I am posting to this list, let me first introduce myself. I am Dietrich Moerman, a computer science student from Belgium (that's the small country known for its chocolates ;)). In my free time, I develop the UseBB forum package. Version 1, written in PHP 4, has been developed and available since early 2004, while version 2 (object-oriented PHP 5.2) is currently under development. Especially the last few years, I have been very aware about security and performance problems, also thanks to Ilia Alshanetsky's talks available at his website. However, recently we have been plagued by a few false reports spread about so called "vulnerabilities" in UseBB 1. Announcements have been made to explain the exact situation and to recover from the damage being done as much as possible. But... what I have found yesterday beats it all. A recent talk from Ilia about PHP security pitfalls (http://ilia.ws/files/phptek2007_secpitfalls.pdf) mentions "useBB" (wrong capitalization, btw) containing exploitable code. The "offending" code was found using Google Code Search and used to demonstrate SQL injection in PHP. First, let me clearly state that there are at this time no known vulnerabilities or exploitable code in UseBB 1. The code which is said to be exploitable is not exploitable at all. Ilia failed to check the code for security measures, if he did he should have noticed that the GET variable can only contain strings with pure integer values ($string == strval(intval($string))). Next to this, all input variables (GET, POST, COOKIE) should be safe against SQL injection. Second, if Ilia was convinced he had found a security issue in UseBB 1, why did he not contact us about it? I thought it was common sense that the first thing you do when having found an issue is contacting the developers and awaiting a fix, before releasing any public information. So, why am I posting this? Mainly to recover from any damage being done. I know PHPTek 2007 is visited by lots of capable PHP developers, some of them who also read php.internals, and many (if not all) of them have been falsely informed about UseBB being a forum system of which the developer(s) don't care about security and have their code full of SQL injection possibilities. Only the exact opposite is true. I also question myself whether it is a good idea to just pick random vulnerable code found using Google code search and place it in much read talks about security on a public website without contacting any developer or awaiting any fix. I know PHP has a bad reputation concerning security, mostly because of the many badly written applications, but randomly putting projects in a bad daylight because of some "this looks like vulnerable" code won't help that much, in the contrary. So, if there are any PHP developers in here who have been badly informed about UseBB, I can only hope their vision about our project will be adjusted. And if any other people here tend to write talks about security containing example pieces of code from real Open Source projects, first do some research and if necessary contact the developer(s), or else just leave the name of the project out. Regards, Dietrich Moerman UseBB Developer Student Computer Science http://dmoerman.be -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mail.force_extra_parameters
On 13 Sep 2007, at 1:04 AM, David Coallier wrote: On 9/12/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: Would anyone object to disallowing setting mail.force_extra_parameters from .htaccess? The problem is that mail.force_extra_parameters can pass arbitrary arguments to mail tool, and some mail tools (especially one, guess which ;) have a lot of parameters, that allow, in particular, reading and writing arbitrary files - which may be a problem with safe_mode (yes, I know, but we are still in 5.x) and open_basedir. I understand that mail.force_extra_parameters was meant for sysadmins anyway, so disallowing .htaccess to change it seems ok. Objections? -- You definitely got a +1 from me for the exact same reasons, it's for sysadmins and if you have that in your .htaccess I believe this is a problem. +1 One less thing for users to change. Regards --jm Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : RE : Namespaces and __autoload()
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] > > Looks like design flaw to me - why not index symbols by name, > you can't > have interface and class with the same name? Right. I was wrong and I have suppressed the 'interface' type in the PHK autoloader. > If we ever extend autoloader to functions, it would be different > autoloader anyway, since existing autoloaders can't support functions. Are you sure we would need to create a new hook ? If the existing autoload handlers receive a request for a function, they search for a class with that name. Apart from a waste of time, it is harmless. We can even have BC : you just have to declare your autoload handler with an optional second argument, whose default value is 'class'. This would allow new autoload handlers to run on previous PHP versions. Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
