つまらない誤解を招きたくないので、元の文書は日本語で書きます。
オリジナル文書は日本語なので、英語を読んで疑問に思ったら、日本語の方を訳してください。

まず最初に、絶対に譲れない線を書いておきます。
「XOOPS_TRUST_PATH 内にアクセスできないこと」というのは、「努力目標」ではなく「仕様」です。

確かにDocumentRoot外にファイルを置けないようなホスティングサービスは事実としてあります。また、XOOPS_TRUST_PATH直下に.htaccessを置いても無視されるケースもなくはないでしょう。

しかし、その両方を兼ね備えてしまうような基本的にクソなサーバが実在することをもって、プライベートエリアを必要とするプログラム（この場合はProtector）にセキュリティ上の問題が発生したと言うのは明らかに論理的な間違いでしょう。

もしそういう論法が成立するなら、ほとんどすべてのWebアプリケーションが脆弱性を持つことになります。CakeでもEthnaでも、DocumentRoot外に置くべきファイル群というのがありますから。


そして、ニュースエントリそのものも論理的に間違っています。Protectorにセキュリティ問題が見つかったのでもなんでもなく、XOOPS_TRUST_PATH 内の直アクセスについての注意喚起が足りなかった、という話題にすぎないでしょう。問題にすべきは、インストーラやドキュメントの方でしょう。

さらに、それによってxoops.orgが用意したProtectorへのパッチがふるってます。
なんでプライベートエリアに置かれることが大前提であるファイルに、いちいちpreg_replace()なんて重い「サニタイズ」処理を入れなきゃいけないのでしょうか。

そういう馬鹿げたチェックが嫌だからこそ、XOOPS_TRUST_PATHという概念を持ち込んでいるんです。preg_replace()はもちろん論外ですが、もっとずっと軽い処理である
てな一行を各ファイルの先頭に入れる、という妥協案さえも受け入れることはできません。

なぜなら、それは「XOOPSにもプライベートエリアが必要だ」ということを理解して、XOOPS_TRUST_PATHという概念に賛同してくれた他の開発者全員への裏切り行為になるからです。

もしProtectorがそういう改変を受け入れてしまったとしたら、他のD3モジュール群すべてに同じ改変が必要になるでしょう。TRUST内には各種ライブラリ・キャッシュ・アップロードファイル・ログ・セッション等、直アクセスを想定していないファイル群がごまんと置かれます。それらをどうしろというのでしょう？

一応、phppp氏との約束もあるので、Protector 3.22のセキュリティガイドに、XOOPS_TRUST_PATHがちゃんとプライベートになっているかどうか、というチェッカを実装しておきました。
（ROOT_PATHとTRUST_PATHの相対パスをとって、直アクセスを試みるもの）

それが私からの最終回答です。