Bug#980275: Please depend on media-types instead of mime-support
Le Sun, Jan 17, 2021 at 11:28:03AM +0900, Charles Plessy a écrit : > > `mime-support` is now a transitional package, and it would be great if > users could be able to remove it after the _Bookworm_ release. > > Please Depend on `media-types` instead of `mime-support` if you only > need the `/etc/mime.types` file. Hello, now that Bullseye is released, it would be great if you could depend on media-types instead of mime-support. Have a nice Sunday ! Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Bug#980275: Please depend on media-types instead of mime-support
Package: apache2 Dear apache2 maintainers, I have recently split the `mime-support` package into two: `mailcap` for the mailcap system, and `media-types` for providing `/etc/mime.types`. The goal is to allow minimal systems without `mailcap`. `mime-support` is now a transitional package, and it would be great if users could be able to remove it after the _Bookworm_ release. Please Depend on `media-types` instead of `mime-support` if you only need the `/etc/mime.types` file. Have a nice week-end, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote: This sucks. In hindsight, maybe the mime.types change should have been deferred until we ugrade to apache 2.4 and people have to adjust their configs anyway. But I think it's too late now to go back. And leaving the *.php.foo problem there for yet another release cycle would not have been a good solution either. Le Mon, Oct 08, 2012 at 03:38:10PM +0200, Ondřej Surý a écrit : Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? That I think would justify change in the mime-support package. Too much breakage on every front now. Hello Ondřej, Stefan, and everybody, Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Of course, it is even better if there is an easy way to adjust the priority of the SetHandler statement of php5_cgi.conf in a way that does not break FastCGI configurations. What do you think ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121011000648.gc27...@falafel.plessy.net
Re: Possible release note for systems running PHP through CGI.
Le Mon, Aug 20, 2012 at 02:57:10PM +0200, Ondřej Surý a écrit : I have prepared new update for PHP based on comments from d-d. The commit is here: http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commit;h=72eef08994f65b227103509617652d7c0bf0587a Hi Ondřej, many thanks for this work. Charles, did you test that or you base that claim on Christoph's mails? I have just tested both php5-cgi in standard configuration as recommended in README.Debian and this claim doesn't seem to be true: $ wget -q -O - http://localhost:8080/index.php bar $ wget -q -O - http://localhost:8080/index.php.jpeg ?php echo 'foo'; ? I did not test, and was trusting from http://bugs.debian.org/589384, which requested the removal of the PHP media types for Wheezy, that the problem was still present in some configurations. Good to see that we are heading towards a solution anyway. What shall I do with #674089 ? I can reassign it to php5-cgi so that your next upload closes it, or do we still need release notes ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120820133509.gb6...@falafel.plessy.net
Re: Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Dear all, thanks everybody for your patience. I know how frustrating it is when one discussion has to be restarted from scratch because of newcommers. I understand that Christoph is not satisfied about the final implementation and, in his opinion, a lack of optimisation, but I cannot comment on that part and I think it should be the topic of a separate bug if that discussion has to continue. As far as the mime-support package is concerned, I think that we reached the consensus that we will not add the entries back, and that the consequences will be documented in the php5-cgi package's NEWS file and in the release notes. I have asked for comments about our current strategy on debian-devel and debian-release. http://lists.debian.org/msgid-search/20120819021726.gc20...@falafel.plessy.net Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120819022820.gd20...@falafel.plessy.net
Re: Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Le Thu, Aug 16, 2012 at 01:14:58AM +0200, Christoph Anton Mitterer a écrit : On Thu, 2012-08-16 at 00:24 +0200, Stefan Fritsch wrote: Stefan, can you please elaborate on what you mean with magic MIME types? (you're talking about MIME type discovery via libmagic or similar? That would be not what's suggested above!) The mime types that are also handler names and cause mod_php to execute scripts, i.e. application/x-httpd-php and application/x-httpd- php-source. Using these as mime types is dangerous because they may also cause things named like foo.php.bar to be executed. Well the same is (IIRC) the case when you use handlers? No? Anyway,... the configuration snippets I proposed in #674205 are _NOT_ vulnerable to the issue you describe, even though using AddType. btw: I've emphasised this several times already,... Dear all, is the following summary accurate ? - In Squeeze, using default configurations, files with .php in their name such as foo.php.jpeg are executed as PHP scripts by the Apache web server. - To solve that problem, the media (MIME) type for PHP has been removed from /etc/mime.types (http://bugs.debian.org/589384). - This breaks the websites executing PHP scripts through php5-cgi, and a solution will be documented in the php5 package's NEWS file, and the same text will be proposed to the release notes (http://bugs.debian.org/674089, work in progress). - Unfortunately, the proposed solution exposes these websites to the original problem that caused the PHP media types to be removed from /etc/mime.types. If the last point is true, I wonder how the other distributions are solving it, given that in Fedora and Ubuntu, /etc/mime.types also does not contain the PHP media types. Can somebody investigate ? I think that I do not understand the problem well enough to be that person. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816230040.gb31...@falafel.plessy.net
Re: Bug#674089: [php-maint] Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Hi Ondřej, On Tue, Aug 14, 2012 at 2:50 AM, Charles Plessy ple...@debian.org wrote: Yes, I will probably add NEWS file to php5-cgi. Do you already have some text which can be added to release notes or we still need to cook something up? I would like to keep this text in sync. For the moment there is the draft proposed by Christoph at http://bugs.debian.org/674089#66 --- mime-types package dropped non-standard definitions for PHP that might affect any systems using PHP --- The package mime-types has dropped the following non-standard definitions: application/x-httpd-phpphtml pht php application/x-httpd-php-source phps application/x-httpd-php3 php3 application/x-httpd-php3-preprocessed php3p application/x-httpd-php4 php4 application/x-httpd-php5 php5 Systems, especially webservers (including but possibly not limited to the Apache HTTPD Server) may have used this to mark files as having the a PHP Internet Media Type (commonly known as MIME type). They may have used it further, to determine that such files are to be interpreted by PHP rather than served as normal files. If a webserver would not consider these files to be interpreted anymore this would have at least the following effects: - PHP web programs/sites no longer work - PHP files are directly exposed, which may be a security problem In order to avoid any problems, read the README.Debian from the php5-common package on how to correctly configure PHP (examples are provided for the Apache HTTPD Server) and take care, that and PHP files intended to be interpreted are recognised as such (typically by adding MIME-Type or handler definitions in the webserver configuration). More information can be found in bug #674089 and partially in #674205. --- Once we have a final text, and once you have added a NEWS file to php5-cgi (or decided to not do so), I will take care of doublechecking on debian-devel and debian-release that there is a rough consensus for our approach. By the way, may I ask you a favor ? In http://bugs.debian.org/661240, filed on mime-support, a user reported that the upgrade broke his installation of WorPpress in a strange way, where only some PHP files are executed and others are displayed as source code. I can't understand why such a thing would happen, so I do not know what to answer him. Do you have a suggestion ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120815000243.gi4...@falafel.plessy.net
Re: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Hi Christoph and PHP maintainers, my answers follow this long quote about a possible release note. For those in CC, please tell if you do not want to get copies anymore. Le Mon, Aug 13, 2012 at 01:44:23AM +0200, Christoph Anton Mitterer a écrit : What about: --- mime-types package dropped non-standard definitions for PHP that might affect any systems using PHP --- The package mime-types has dropped the following non-standard definitions: application/x-httpd-phpphtml pht php application/x-httpd-php-source phps application/x-httpd-php3 php3 application/x-httpd-php3-preprocessed php3p application/x-httpd-php4 php4 application/x-httpd-php5 php5 Systems, especially webservers (including but possibly not limited to the Apache HTTPD Server) may have used this to mark files as having the a PHP Internet Media Type (commonly known as MIME type). They may have used it further, to determine that such files are to be interpreted by PHP rather than served as normal files. If a webserver would not consider these files to be interpreted anymore this would have at least the following effects: - PHP web programs/sites no longer work - PHP files are directly exposed, which may be a security problem In order to avoid any problems, read the README.Debian from the php5-common package on how to correctly configure PHP (examples are provided for the Apache HTTPD Server) and take care, that and PHP files intended to be interpreted are recognised as such (typically by adding MIME-Type or handler definitions in the webserver configuration). More information can be found in bug #674089 and partially in #674205. --- As you can see, I personally would put the burden of explaining how to (securely) configure PHP to the PHP packages... I have some discussions about that with Ondřej in #674205 ... I'm not yet fully happy with it (see there)... and although he closed the bug and said he'd have applied some of my proposals, I could not yet find these changes there. I think that the changes are the following: - index 26fe076..99c37c6 100644 (file) --- a/debian/php5-common.README.Debian +++ b/debian/php5-common.README.Debian @@ -78,6 +78,11 @@ PHP 5 CGI and Apache HTTP Server installed side-by-side and both were automatically enabled, the results would be a bit confusing, obviously. + You should also be aware, that a server deployed in CGI mode is open + to several possible vulnerabilities, see upstream CGI security page + to learn ow to defend yourself from such attacks: + http://www.php.net/manual/en/security.cgi-bin.php + To use php5-cgi with Apache HTTP Server: 1) activate CGI (it's on by default in default debian setups) a) If using the prefork MPM, use 'a2enmod cgi' @@ -86,8 +91,10 @@ PHP 5 CGI and Apache HTTP Server 3) Add the following to a config snippet in /etc/apache2/conf.d IfModule mod_actions.c ScriptAlias /cgi-bin/php5-cgi /usr/lib/cgi-bin/php5 - Action php5-cgi /cgi-bin/php5-cgi - AddHandler php5-cgi .php + Action application/x-php /cgi-bin/php5-cgi + FilesMatch \.php$ + AddType application/x-php php + /FilesMatch /IfModule Note: more modern way of doing this is to install php5-fpm package @@ -140,4 +147,4 @@ Further documentation, errata, misc. If after reading the documentation in this file you still have unanswered questions, that's a good next place to go. - -- Ondřej Surý ond...@debian.org, Sun, 8 Apr 2012 22:00:59 +0200 + -- Ondřej Surý ond...@debian.org, Mon, 6 Aug 2012 12:49:51 +0200 - For the release note, I think that it would have to clearly indicate that this only impacts the system running PHP scripts via the CGI package, which in my understanding are the minority. If upgrading to Wheezy would unconditionally break these systems, then I think that a NEWS file in php5-cgi would be an important complement, as it would interrupt the upgrades ran in standard conditions. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813230601.gb8...@falafel.plessy.net
Re: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Le Tue, Aug 14, 2012 at 02:27:33AM +0200, Christoph Anton Mitterer a écrit : Question: Can any other webservers use mod_php? If so, they _might_ be vulnerable, as the supplied Apache config snippet probably doesn't apply to them. Most people I know run either CGI (if just security counts) or FPM (if security and/or performance counts)... If upgrading to Wheezy would unconditionally break these systems, No,... this is not necessarily the case,.. if people have e.g. set their own handlers/mime-times for php in apache. Hi again, I have the following questions for the PHP maintainers. 1) Can libapache2-mod-php5 be vulnerable ? 2) The user base of php5-cgi is thousands (see Popcon URL below). What feedback did you have from Sid and Wheezy users ? http://qa.debian.org/popcon-graph.php?packages=php5-cgi+libapache2-mod-php5show_vote=onfrom_date=to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 3) Will upgrading unconditionally break sites using php5-cgi with Apache ? 4) Would you like to implement some of Christoph's suggestion or add a NEWs file to php5-cgi ? On mime-support's side, I will not add a NEWs file, as it would interrupt the installation of tens of thousands of systems which do not run PHP. After your answer, I propose to send a brief summary to debian-release and debian-devel, proposing reassign the bug to the release notes with the same severity. Have a nice day, -- Charles Plessy Co-maintainer of the mime-support package Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120814005046.gg4...@falafel.plessy.net
Re: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Le Wed, Aug 01, 2012 at 01:54:30AM +0200, Christoph Anton Mitterer a écrit : I guess what I propose here (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674089#35) is the best/safest way to go: 1) something in the release notes 2) the NEWS files of at least mime-types, apache, php5-common (mod_php is not enough) likely also lighthttpd... maybe even more (nautilus? everything using mime-types?) 3) don't then add any default PHP type/handler definitions in the apache config... remove any existing ones. Dear all, do I understand correctly that the problem would be solved by documenting the change in the release notes ? If yes, can somebody write a draft and reassign this bug to the release-notes packages ? Have a nice day, -- Charles Plessy Co-maintainer of the mime-support package Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120804034438.gd23...@falafel.plessy.net
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Sun, Jul 06, 2008 at 11:05:27AM -0700, Russ Allbery a écrit : Stefan Fritsch [EMAIL PROTECTED] writes: On Saturday 05 July 2008, Charles Plessy wrote: - if yes add a link to a configuration file in /etc/apache2/conf.d You can add that file or the link unconditionally. That would really upset me if I were a systems administrator. Most of my Apache configurations have multiple virtual hosts, and having some package randomly add itself to the namespace of every virtual host I run, possibly taking over pages that were currently serving some other purpose, would be extremely annoying. I'd want at least a debconf prompt before something added itself to the global Apache configuration. Well, it definitely makes sense, but it makes me wonder if my goal is achievable. The frontend I package is as useful on purely local systems (a laptop for instance) as on servers (indeed if you search for `emboss explorer' you will find sites running it). So if the package does things automatically, it can annoy system administrators who run it on a dedicated web server. But if the package pulls apache2 and installs its configuration automatically, end users will benefit of it as just another graphical interface, with the only peculiarity that it needs a browser to be used. How can this conflict of interest be solved? EMBOSS explorer is a nice interface, and I really would like to provide to end users with no command-line interactions with the system. How about making it available only for localhost by default? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Mon, Jul 07, 2008 at 04:05:54PM +0200, Mike Hommey a écrit : Why not have your package create its own apache instance, with its own config and its own port ? Probably because I have no clue on how doing this cleanly ;) But why not? An in that case, why not something lighter than Apache… Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Sun, Jul 06, 2008 at 11:02:50AM +0200, Stefan Fritsch a écrit : On Saturday 05 July 2008, Charles Plessy wrote: - restart apache. A reload should be enough. Don't restart apache if it is not necessary (as it aborts active connections and may require the admin to enter ssl key passphrases, etc.). Thanks a lot for the answer. Would something like: if [ -x /etc/init.d/apache2 ]; then if which invoke-rc.d /dev/null 21; then invoke-rc.d apache2 reload else /etc/init.d/apache2 reload fi fi be acceptable? It would be nice though, if the restart was only done when necessary (on new installs and on upgrades if the config file changed). Hmmm, I am not sure to know how to test if the config was changed... Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Dear Mentors and Apache maintainers, In the course of making a package (emboss-explorer) FHS-compliant, I moved its files from /var/www to /usr/share. I would like http://localhost/mypackage to work after package installation just as before when the package was installing its files in the default document root of apache2 (and maybe other webservers). For the moment I will only support apache2 because of my lack of knowledge of other systems, but of course suggestions on how to achieve this with other httpd-cgi servers are appreciated. After insallation, the package must: - Check if apache2 is there, - if yes add a link to a configuration file in /etc/apache2/conf.d - restart apache. Of course, I can cut-and-paste from the postinst script of other packages already implementing this, but before doing so I was wondering if there were some factorised code somewhere that I could call instead. (I am also wondering if I have to ask the user wether he agrees to restart apache...) In the worst case, I can just document in README.Debian that the link has to be created and apache restarted, but as the package I am working on is a www interface to a command-line program, I would prefer that it does not require command-line intervention, since its public is partly composed of persons who are not comfortable with command-line. PS: would the DPKG triggers be a good mechanism to deal with this apache restarting tasks? Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
