[Bug]: Detection::detectString() / detectContent() never use finfo – missing use finfo; (regression from #54077) #66239

⚠️ This issue respects the following points: ⚠️

• This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
• This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
• I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
• I agree to follow Nextcloud's Code of Conduct.
• I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

Since #54077 (refactor(IMimeTypeDetector): streamline finfo usage + misc tidying), lib/private/Files/Type/Detection.php uses class_exists(finfo::class) and new finfo(...). The file is in namespace OC\Files\Type, but there is no use finfo; import. finfo::class therefore resolves to OC\Files\Type\finfo, class_exists() is always false, and the finfo branch never runs, even when ext-fileinfo is loaded.

Affected: detectString() (line ~302) and detectContent() (line ~228). Present in v35.0.2, stable34, stable35 and master.

Effect: detectString() falls back to writing a temp file and calling detect() → detectContent() → mime_content_type(). That result goes through getSecureMimeType(), which maps MIME types that are not in the mimetype list (e.g. image/vnd.microsoft.icon) to application/octet-stream. Before the refactor, finfo_buffer() returned the real type.

Visible consequence: In the Mail app, favicon avatars no longer show up. FaviconSource calls IMimeTypeDetector::detectString(), gets application/octet-stream for .ico favicons, and AvatarService::hasAllowedMime() rejects the result. I suspect this is also why FaviconSourceTest::testFetchNoCacheFiles was dropped as "flaky" in nextcloud/mail#12578.

Steps to reproduce

<?php
require 'lib/base.php';
$d = \OCP\Server::get(\OCP\Files\IMimeTypeDetector::class);
$ico = file_get_contents('https://heise.de/favicon.ico');
var_dump(class_exists('OC\Files\Type\finfo'));                // false
var_dump($d->detectString($ico));                             // "application/octet-stream"
var_dump((new \finfo(FILEINFO_MIME_TYPE))->buffer($ico));     // "image/vnd.microsoft.icon"

Expected behavior

detectString() returns image/vnd.microsoft.icon, as it did before #54077.

Nextcloud Server version

35

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.4

Web server

Nginx

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response