Re: RFS: phpmyid
Vincent Bernat wrote:
> OoO En ce début d'après-midi ensoleillé du jeudi 28 août 2008, vers
> 15:04, Andreas Schildbach <andreas@schildbach.de> disait :
>
>>> In debian/control, your dependencies are too strict.
>
>> I relaxed the dependencies. However, how can I know that my package
>> actually works with all HTTP daemons? I cannot test them all.
>
> It is not really your matter. You provide a configuration file for the
> one or several HTTP daemon and let the user handle other cases. The
> point here is to not force the user install Apache while he wants to use
> another daemon to run this package.
> Depends: apache2 | httpd, php5
This should actually be apache2 | httpd-cgi, php5; as a simple httpd like
dhttpd Provides: httpd but won't be of any use when the user wants to run
php5-cgi (which is the only web server non-apache SAPI of php being shipped
atm).
>
>>> I think that you should not ship htaccess file (or as documentation).
>>> It is usually better to put all configuration in Apache configuration
>>> file. For example, by default, rewrite rules are not authorized in
>>> htaccess. You can put the content of htaccess in your apache2.conf
>>> file for example.
>
>> What do you mean by "rewrite rules are not authorized"? Is it perhaps
>> better to not deviate from upstream in this case (htaccess comes from
>> upstream)? I could try to convince upstream to change this with the next
>> version.
>
> The default configuration of Apache does not allow to put rewrite rules
> in .htaccess files. In post-lenny, nothing will be authorized by default
> in .htaccess. Therefore, a user modifying .htaccess will get a non
> working configuration unless it also modifies an AllowOverride clause.
>
> Upstream ships .htaccess because it allows user to just unpack the soft
> in some directory and make it work without modifying anything else (but
> as pointed above, this won't work on a default Debian system). Since you
> are packaging the software for Debian, you don't need to use .htaccess
> because you can alter Apache configuration (usually by dropping a file
> in /etc/apache2/conf.d).
The file is actually useless as it only provides a couple of examples on
what "need to add" when php5-cgi is used (it actually doesn't make any
sense that you need those).
>
> There is no mandatory document about this. You can look at the draft
> policy here:
> http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html
...
Besides that, taking a quick look at the code:
> // if neither, offer the trust request
> $q = strpos($profile['req_url'], '?') ? '&' : '?';
wrong assumption, strpos returns false but might also return 0 which in that
case would be evaluated just like false.
Oh, and by looking at the code:
> # 'allow_gmp' => false,
> # 'allow_test' => false,
> # 'allow_suhosin' => false,
Enabling allow_gmp requires the user to have the php5-gmp extension
installed, so it might be a good idea to Suggests (probably not Recommends
as it can fall back to use bcmath which is a built-in extension of the php5
packages) it.
I don't see any real reason for this:
> $extension_b = array('suhosin');
> foreach ($extension_b as $x) {
> if (extension_loaded($x) &! $profile["allow_$x"])
> error_500("phpMyID is not compatible with '$x'");
> }
> phpMyID is NOT compatible with Suhosin or other hardened PHP systems
(Debian
> users take note).
> *) Received error: "phpMyID is not compatible with 'suhosin'"
>
> Suhosin is a security add-on for PHP which, amongst other things,
removes
> PHP's ability to open and access multiple sessions at one time. Simply
put,
> phpMyID is reliant upon this feature, and will therefore not work with
a
> hardened PHP.
>
> To make phpMyID work with Suhosin, you can try the following:
> 1) Set the profile key 'allow_suhosin' to "true" in your config file.
> 2) Set "suhosin.session.encrypt Off" in either your PHP/Suhosin config
file,
> or as a php_flag in your httpd.conf (or .htaccess).
>
> See: https://www.siege.org/forum/viewtopic.php?pid=3167
You should really clarify that.
Anyway, the code is prone to XSS attacks (I could actually be more specific
if you want me to, but better let upstream review all the code) on the html
it prints and the headers it sends. It even relies on HTTP_HOST and doesn't
perform any sanity check on it.
IMHO the code is not ready to be uploaded as there are security issues that
need to be addressed first and not after it is uploaded to Debian.
Cheers,
--
Atomo64 - Raphael
Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Reply to: