Revert php_fileinfo requirement

You need to rebuild drupal each time you fetch a new version.
If that isn't working, drupal probably changed to much and you should reinstall.
(don't forget to remove the files directory)

I'm confident this will fix your issue. Had the same problem today, reinstalled everything.
Moving to normal for now.

Can you go to admin/reports/dblog ("Recent log messages" under the "Reports" section) and see if there are any messages there? It should be stuff about modules being enabled and the install completing, and then hopefully some clue.

If that doesn't have anything, go to admin/config/development/logging ("Logging and errors" under the "Development" section in "Configuration") and setting the error reporting to "All messages, with backtrace information", and then trying the export again.
Either that will give you more info, or it might add extra info to the log messages.

Thanks for working through this @amool! I'm glad it works now.

Wait shouldn't we add a hook_requirements for php_fileinfo then?

Can we automatically test this?
For manual testing, @amool, could you try installing again but with the extension=php_fileinfo.dll commented out again?

maybe just fileinfo?

/me facepalms

unless bot disagrees.

@larowlan points out we can't test this with the current testbot infrastructure

Committers, please include @amool in the commit message.

Committed 6a8faf5 and pushed to 8.x. Thanks!

I came across this yesterday when doing a fresh install. Right at the start of the installation it came up with a a requirements error with a message to enable the fileinfo extension and wouldn't let me go further. I enabled it and install worked. But, as far as I can see this is not mentioned in the requirements documentation:

• I checked INSTALL.txt and that refers you to http://drupal.org/requirements.
• There I find a link to "More details about PHP requirements" (https://www.drupal.org/requirements/php).
• Fileinfo is not mentioned on that page.

Somewhere, a note about fileinfo needs adding, probably in the "Drupal specific version notes on PHP requirements - Drupal 8" section.

Also having this on DreamHost. Seems like we should do some research to figure out how common this extension is before we make it a requirement?

I got reply from my shared hosting provider:

> Sorry, we had never supported "fileinfo" also, cPanel doesn't recommend installing it prior PHP 5.5
> There are few vulnerabilities which were patched in 5.4.33 (your version) but still...

I suppose many others will have problems with fileinfo extension on their shared hostings as well.

If cPanel do not recommend it prior PHP 5.5 - which is not so widely used yet - is it a good way to make it a requirement?

I'm not sure if this is actually a release blocker (guess it depends on who the other hosts are), but escalating this to get some eyes on it.

Re-titling since I keep looking at this wondering why we don't just add the dependency.

According PHP installation manual the fileinfo extension is enabled by default from 5.3.0 onwards.

Quote from manual.

This extension is enabled by default as of PHP 5.3.0. Before this time, fileinfo was a PECL extension but is no longer maintained there. However, versions prior to 5.3+ may use the » discontinued PECL extension.

Windows users must include the bundled php_fileinfo.dll DLL file in php.ini to enable this extension.

This information and link were added to the PHP documentation page by myself.

Would it be possible to swap out the MimeTypeGuesser if fileinfo is not detected?

@webchick it looks like fileinfo is supported on Dreamhost if you add the extension to php.ini/phprc yourself, at least according to http://wiki.dreamhost.com/Fileinfo

re #26 yes it would be but then we'd have to maintain a replacement in core.
re #27 the disclaimers on http://wiki.dreamhost.com/Fileinfo are hilarious.

While discussing the criticality of this issue we saw the following code:

    private function __construct()
    {
        if (FileBinaryMimeTypeGuesser::isSupported()) {
            $this->register(new FileBinaryMimeTypeGuesser());
        }

        if (FileinfoMimeTypeGuesser::isSupported()) {
            $this->register(new FileinfoMimeTypeGuesser());
        }
    }

inside Symfony\Component\HttpFoundation\File\MimeType\MimeTypeGuesser::__construct

Given that we host on mostly unix systems, the question is why the following condition of FileBinaryMimeTypeGuesser::isSupported() fails.

        return !defined('PHP_WINDOWS_VERSION_BUILD') && function_exists('passthru') && function_exists('escapeshellarg');

These functions are built into php, it is not even an extension ... dreamhost seems to seriously do something crazy
like patching PHP itself and remove stuff from it.

We need some more detailed research.

.

If it was just Dreamhost that'd be one thing, but see also #22. CPanel is installed nearly everywhere. We need more data, probably starting with the hosts mentioned here, particularly GoDaddy: http://trends.builtwith.com/hosting/shared-hosting

And yes, the disclaimers on that page, while hilarious, effectively mean Dreamhost users won't be able to run Drupal 8, because no one in their right mind is going to do that in the face of those warnings. :\ Since DreamHost is apparently running 14% of all the top 100K (3% across all) shared hosting sites on the internet, that seems a pretty big deal.

https://twitter.com/webchick/status/532068668168220672 for now.

Also, adding the issue where this was introduced. Looks like the problem's existed since alpha13.

By default fileinfo isn't enabled on stock cPanel, but will install on stock cPanel with PHP 5.4 once fileinfo is enabled.

Can someone update the summary to give more info about where that symfony class is used or how?

The name alone makes me cringe and think of file-naming security exploits

@pwolanin see the issue in #34. We kept the same mapping as 7.x so the security considerations should be the same I think.

Wrt #30, I had a friend with Dreamhost access check and the 3 conditions for FileBinaryMimeTypeGuesser::isSupported() all pass. So, hopefully this sort of failure isn't totally widespread.

However, patching PHP isn't necessary at all to achieve this effect: PHP allows you to add functions to a disable_functions list in the php.ini file. Those functions presumably fail a "function exists" check, and escapeshellarg is a frequent candidate for this disabling because it is part of code (i.e. shell calls) that shared hosting administrators consider insecure.

It is worth noting that all of those disclaimers seem to be from a legacy era when fileinfo was a PECL extension. If fileinfo has been on-by-default since PHP 5.3, we could probably prevail on Dreamhost (and cPanel) to enable fileinfo by default or provide better guidance about how common it is and get rid of the hilarious red warnings and so forth.

> Drupal\Core\File\MimeType\MimeTypeGuesser uses the Symfony MimeTypeGuesser class when handling files

As far as I can see, the only service tagged by mime_type_guesser is file.mime_type.guesser.extension. I can't see how Symfony MimeTypeGuesser is used.

Nonetheless, it would be a great security boon to use it but I am not sure whether this is critical; we have released a truckload of Drupal versions based on this weak mime guesser.

This is a red herring, filed #2387443: BinaryFileResponse can fail because the core MIME guessing is not added to the MimeType singleton instead.

Ok, so after a big round of discussion/detective work in IRC (thanks dawehner/chx), turns out #2387443: BinaryFileResponse can fail because the core MIME guessing is not added to the MimeType singleton is the root cause of amool's problems.

Therefore, I'd like to solve this issue by reverting the patch in #13 that added fileinfo as a requirement. It turns out this isn't necessary, since Drupal's mime type guesser doesn't require it, and the reason it's resulting in errors about missing dependencies is because Symfony's got some code that's hard-coding a call to theirs.

This would address both the additional requirements issue leading to install failures on some shared hosts, and also leave a clean slate for #2387443: BinaryFileResponse can fail because the core MIME guessing is not added to the MimeType singleton to handle only the parts required to fix the bug.

Here's a patch.

Updating title and issue summary.

Commit it!

Committed 502c78a and pushed to 8.0.x. Thanks!

Summarizing what happened in the issue and on IRC: I need to yell at people to get them to listen to me instead of believing whatever Symfony says. I don't want to yell at people. That hurts people and hurts me. I am, again, out. I thought I can work together with people to get criticals fixed, turns out I can't. Too bad. You'll need someone else to do critical hours.

There are more thoughts swirling in my head , this issue mostly just sparkles writing them down.

1. One of the fundamentals of Drupal were hooks. Instead of doing a requirements-pros-cons analysis based on what Drupal, Symfony and other frameworks did we have not replaced but added Symfony's event system which in every possible way is the exact opposite of hooks: explicit vs implicit, functions vs method, priorities vs weights. It also turned out that the system didn't scale to Drupal's needs so we have overwritten/extended Symfony's relevant parts. More would be needed.
2. One of the fundamentals of Drupal is handling incoming and outgoing links/paths/routing. Instead of doing a requirements-pros-cons analysis based on what Drupal, Symfony and other frameworks are doing we have added Symfony CMF's routing system. When it turned out it (immediately) doesn't scale to Drupal's needs we have overwritten/extended Symfony's relevant parts. However, this was not enough and instead of doing more of this we have decided to solve the performance issues by storing and make routes our central API despite neither incoming nor outgoing links are routes.

Now, let's talk of release. There are two routes ahead: PHP 5 and PHP 6. PHP 6 was poised to be a revolution, had books printed then stalled and never was released. PHP 5.0 was a horrible release, PHP 5.0.5 broke things so badly several people didn't touch PHP 5 until GoPHP years and years later made them. PHP 5.2 was a pleasant release.

I do not think the community can fix the mess created in any reasonable time frame. klausi had the right idea: pick a date, I recommend two weeks after DrupalCon Los Angeles and release Drupal 8.0.0. Deadline makes things happen. We know that. We can rally people much better around a big countdown than a critical countdown marker that can not reach zero.

Edit: cross-posted to the release issue.

Taking a break sounds like a very good idea if that's how you interpreted this afternoon's events.

I'm happy to run with core critical hours until we can find someone more suitable. I still think it's a great idea for creating momentum around critical issues, especially from people not in the list of top 10 D8 contributors.

8.0.x installation works on my shared hosting now. Nice to see d8 installed for the first time. :)

Thnx!

I am not contesting the quality of Symfony / Symfony CMF. In the past perhaps I did, that was stupid. However, that was often a knee jerk reaction to the prevailing and equally stupid "Symfony good, Drupal bad" default viewpoint of some? many? developers.

No, Symfony is certainly good at certain things and Drupal is certainly good at certain things and where Drupal 8 has problems is these two things don't quite match. This bug is a textbook case:

Symfony has a MIME guesser that relies on tried and true tools which give you a very good MIME guess based on the contents of the binary itself. Drupal has a MIME guesser which gives you a poor guess based on the extension of the file. The latter, however is available everywhere. Also, Drupal does not rely on the guess from the MIME guesser for security and as such a weak guesser that is correct in most cases and available everywhere was fine until now. And the best solution is to run Symfony's strong MIME guesser where possible and runs Drupal's when not. Do you see finally what I am saying? Symfony and Drupal both make compromises. Symfony tends to be more correct in theory and works better for people building neat web applications on top. Drupal, on the other hand, tends to be more practical to be workable for an extremely wide range of users. The integration can be great but the road leading there is rocky.

What makes me mad is when the fine tuned, battle tested practical solutions of Drupal are changed to fix bugs in this new amalgamation of Drupal and Symfony. Instead, the default bugfixing method should be to strengthen the integration, to override/extend Symfony with Drupal's solutions. If you don't do this then you move sideways and not forward towards a release as this issue showed.