It is a small addition but really useful. If you already use dotclear2, you may have missed the new feeds options (see the URL handlers code). It is now possible to create a feed for a given tag. For example, my PECL related entries can be fetched from:

http://blog.thepimp.net/index.php/feed/tag/PECL/rss2

By the way,the beta4 is out, go fetch it!

• dotclear2 beta4
• dotclear homepage

(Update on 2006/12/22 click to read more)

While reading the very long "taint mode", I had more and more the feelings that many developers ignore ext/filter or simply work around it. At the same time many argue about the necessity of this taint mode. It is a self contradiction and makes me wonder about the real reasons, I will post later about the existing taint mode available since php 5.2.0.

On the other hand, the same persons worked around ext/filter with ugly hacks. Edin pointed me to one of these horrible code sin Serendipity, as I saw this code in other applications like flyspray, I think it is time to raise your attention about what to do not do (The enlightenment has been brought to the author of this code, which is the same in flyspray and s9y . Here is what you should NEVER do:

<br />
if (extension_loaded(&#8216;filter&#8217;) && filter_id(ini_get(&#8216;filter.default&#8217;)) !== FILTER_UNSAFE_RAW) {</p>
 
    if(count($_GET)) {
        foreach ($_GET as $key => $value) {
            $_GET[$key] = filter_input(INPUT_GET, $key, FILTER_UNSAFE_RAW);
        }
    }
    if(count($_POST)) {
        foreach ($_POST as $key => $value) {
            $_POST[$key] = filter_input(INPUT_POST, $key, FILTER_UNSAFE_RAW);
        }
    }
    if(count($_COOKIE)) {
        foreach ($_COOKIE as $key => $value) {
            $_COOKIE[$key] = filter_input(INPUT_COOKIE, $key, FILTER_UNSAFE_RAW);
        }
    }
    if(isset($_SESSION) && is_array($_SESSION) && count($_SESSION)) {
        foreach ($_SESSION as $key => $value) {
            $_SESSION[$key] = filter_input(INPUT_SESSION, $key, FILTER_UNSAFE_RAW);
        }
    }
 
	<p>}<br />
 

It is not only plain stupid (to be polite) but laziness is the first cause of most security flaws. Do it the right way:

• Implement your input functions as fall back when filter is not available or use filter in them
• Never use directly the super globals outside these functions

But to do it like in the code above is calling for troubles.

Update

First, I like to say that this post is not an attack against the Serendipity or flyspray developers, I hope they don’t feel offended . My comments and suggestions are related to this exact portion of code. Now that I clear the misunderstanding with Stefan. Let start to answer.

As a christmas wonder, we do agree on one point, each project should have its own input functions. This was the main point of my post. This solution has the advantage to centralize the operation and to force the developers to use these functions (coding standard or whatever you use to define rules within a project). It will also protect you from your own laziness/distraction

Stefan was saying that everything in filter can be implemented in userland, that’s plain wrong. There is no way to provide input filtering in PHP while preserving the original data. As soon as you replace the contents of a superglobals, the original contents is not available anymore (if you rely only on GPC super globals). And this is one of the good thing in filter, the ability to fetch the same input using different filters when and where you need it. Using your own input filtering can provide similar features but with no waranty that one will use them or will not fetch the original values before the initialization of your input filters.

"ext/filter is just a new irritating API to already existing functionality"

I suppose Stefan was talking about the default filter, which is set to "unsafe_raw" by default. "unsafe_raw" does not filter the inputs, they are left intact, 100% backward compatible. Yes, if a host uses a default filter, this change is certainly justified or requested, does that mean you are out of luck and ext/filter is plain crap? no. As I said in my post, if you have your own input functions, it is a piece a cake to provide full support of the new ext/filter within your applications or modules. Do I really have to remind that havining GPC super globals all over the code is not a good practice?

"that potentially introduces new security holes, because it reimplements existing stuff again"

Aber sicher! Come back, every single line of code potentially introduces security issues or bugs. That’s true for everything, even for S#?*in patch. Is it an argument to do not provide ext/filter? Be serious half a second.

"ext/filter is a similar stupid idea like magic_quotes_gpc. When you use it, the security of your application depends on the server configuration and no longer on your application code."

That’s another (double) wrong statement. As said earlier, there is no default filter by default. That does not prevent you to use ext/filter API to fetch what you need. It is part of your development rules, as you have to think about what you are doing instead of spreading the gpc all over your apps. When a default filter is used, using the filter functions will give what you need and when you need it, regardless of which filter is used by default.

I do consider the super globals (_POST/_GET/_COOKIE/...) as a mistake, their usages should be restricted to a very small area of an application. ext/filter is a step to the right direction (it is not the panacee, nothing can solve all needs or problems).

And about the server configuration, no matter what you do or say, the security of your applications depends (partially or totally) on it.

"Supporting ext/filter makes your code more complex"

For what I heard and given my own experiences, it makes the code less complex, easier to maintain and much more clear (all inputs management code is centralized, policy can be enforced, a script arguments are clearly identified, ...). You do not have to worry about wide GPC usages all over your applications (as developer lead or when you audit your apps, it is an important factor). And yes, the centralization of the input filtering can be done without ext/filter. ext/filter provides a way to force it.

"and in case of a bug in ext/filter you have no chance to protect your users, because security only relies on the admin’s will to upgrade."

You can build filter as a shared module. By the way, if I use the S#?*in patch to secure my application/php, am I not in the exact situation? My security only relies on the admin’s willing to a) apply an unofficial patch to php and b) keep it uptodate by patching and recompiling? or maybe you have no bug.

"Additionally ext/filter will keep a copy of all GPC variables in memory"

I’m fixing this issue, by providing a true JustInTime for the auto global (and unicode support).

Update #2

PHP codebase must be pure crap from a security point of view, that’s the commercial and marketing main argument of the Susoshin patch. Whether it is true or not, I let you make your own judgments (Zeev’s reply to the /. misquote is a good place to start).

But now one thing is sure, all attacks and recent moves have one and only goal, self marketing and promotions. How can it profitable if there is "virtually" nothing wrong in PHP code or features? The good thing is that this position is now clarified and my last hopes about their real intention have been killed (no big deal). Let enjoy 2007, I was slowly getting bored lately, 2007 sounds promising </Dallas>

Yet another PECL release, htscanner 0.6.2 is out. This release fixes a annoying but minor bug in the shutdown function. A new error message has been added when no translated path has been found.

I’m wondering if a function to manually clear the cache for a given document root (like you can clear the cache for your document root only) can be useful. Let me know if you need it, I can add it before I freeze this extension until the first stable release.

• htscanner homepage
• htscanner download

Thanks to Ron Korving and Ilia Alshanetsky, a couple of thread unsafety issues have been caught in php codes, a complete list of Ron’s review can be read in his original post. The fixes have been commited already, 5.2.1 will contain them.

So far, only one was discovered in zip, zip 1.8.3 contains the fix.

• Ron’s post
• Zip Homepage
• Zip Download

0.6.1 has just been released. It is a bug fixes release only. One leak and some string optimizations. See the full changelong here.

• htscanner homepage
• htscanner changelogs

And extra Rheolism is an anhanced version with scoring, game over screen or drop key

• Extra Rheolism

htscanner 0.6.0 has been released. It caches the ini settings instead of looking for htaccess files in the current directory and its parents. The performance impact is yet minimal.

A new ini setting defines the cache lifetime in seconds: htscanner.default_ttl, the default lifetime is 5mins.

Next step, bring this extension to a stable state before adding any new features.

• htscanner homepage

Loosing his old URLs is not always a good thing and not only for the ranking in google. I got a couple of requests to restore them, here you go, old post URLs are back.

Here is the lighttpd rewrite rules for the old rss.php file and the post access, if anyone needs it (not really rocket sciences, but copy/paste can be faster :

         url.rewrite-once = (                 "^/rss\.php" => "/index.php/feed/rss2",                 "^/index\.php/([0-9]{4}.*)" => "/index.php/post/$1"         ) 

Update You can find further rules for apache’s mod_rewrite in the dotclear’s forum. If you need some of them for lighttpd, let me know, I can try to "port" them (I’m happy with the two rules above).

A little note about a Zip bug fix release. The latest releases did not work with php 5.1.0, 5.1.1 and 5.1.2. A 5.1.2+ internal function was used. It should work again smoothly.

• homepage

A quick note about the htscanner windows binaries, they are now available on pecl4win. I will also try to run more tests on windows, especiallly IIS + fcgi.

• htscanner
• htscanner dll