fix: prevent arbitrary file write via unsanitized SVG/MVG bitmap previews (OC10-164)

[oc-tmueller]

Summary

Bitmap::getResizedPreview() sanitized SVG content before handing it to Imagick::readImageBlob(), but fell back to the original, unsanitized bytes whenever the sanitizer returned an empty string. SVG::sanitizeSVGContent() returns '' for any content libxml cannot parse, not just genuinely malformed SVG - so a malformed SVG (or any non-XML payload such as a raw MVG script) reached ImageMagick unsanitized. There, an <image xlink:href="MSL:..."> or an MVG fill 'url(...)' primitive can execute an MSL script that reads and writes arbitrary files as the web user (CVSS 8.8).

• Bitmap::getResizedPreview() no longer sanitizes-then-falls-back. It now rejects any content whose libmagic-detected media type is text/*, image/svg+xml, application/xml, or image/x-mvg before ever calling into Imagick (isDangerousToDecode()), and goes through ImagickFactory::create() so the svg:sanitize/svg:embed/svg:decode hardening options apply here too.
• SVG::sanitizeSVGContent()'s return type changes from string to ?string, returning null when the underlying sanitizer does not return a string, so callers can distinguish "could not sanitize" from "sanitized to an empty document". The SVG provider's own call site now bails out on null instead of silently passing empty content to Imagick.
• SanitizeTest is updated: SVG content fed to a Bitmap provider (PDF, Font) now must return false instead of a rendered PNG, since Bitmap providers no longer attempt to handle SVG-shaped content at all - that's the dedicated SVG provider's job. Added regression cases for a malformed SVG with an MSL xlink:href, a raw MVG script, and a well-formed SVG - all must return false from a Bitmap provider.

Note: image/x-mvg is included in the deny-list because libmagic (file-5.41, standard Ubuntu magic database) classifies a raw MVG script as image/x-mvg, not as any text/*/xml type - without it, the MVG regression case would not be blocked.

Not in scope for this PR (flagging separately): Bitmap::getThumbnail() leaks $stream when getResizedPreview() throws - it returns at line 54 before the fclose() at line 57. That's a resource leak, not a security defect, and deserves its own focused PR.

Test plan

• make test-php-style
• make test-php-unit TEST_PHP_SUITE=tests/lib/Preview/ - 58 tests, 8 skipped (unrelated missing Movie/Office providers), 0 failures
• Confirmed RED before the fix: 6/8 SanitizeTest cases failed against unfixed code (the well-formed/sanitizable/malformed SVG cases all reached Imagick and rendered); confirmed GREEN after
• tests/lib/Preview/PDFTest.php (testimage.pdf) and tests/lib/Preview/BitmapTest.php (testimage.eps) still produce previews

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[kw-fscheuer]

Follow-up suggestion rather than a change request on this PR — the fail-open fix here looks right to
me, and this is about removing the bug class rather than the instance.

What this approach leaves open by design. isDangerousToDecode() is a deny-list over the
sniffed type, and the decode that follows re-derives the format independently. Two consequences:

1. The provider is selected by extension; the coder is selected by content. Detection.php maps
   an extension to a MIME type, which picks the provider — but readImageBlob() passes no format, so
   ImageMagick consults its own magic table (magick/magic.c, ~130 entries) and selects whatever the
   bytes look like. The set of coders reachable from any Bitmap provider is therefore the whole
   sniffable set, not the single MIME type the provider was registered for. Some of those coders
   shell out to external binaries through delegates.xml.
2. Two different sniffing engines make the decision and take the action. The security check uses
   libmagic (getMimeTypeDetector()->detectString()); the decode uses ImageMagick's own table. Where
   they disagree, the check passes on libmagic's answer and the decode happens on ImageMagick's —
   the same shape as the libxml-vs-ImageMagick differential that made the original fail-open
   reachable in the first place.

There is a concrete residual path in this class. I've put the specifics on OC10-164 rather than here.

Suggested follow-up: pin the coder instead of letting ImageMagick guess. Each provider already
knows its format — SGI is registered for image/sgi and nothing else — so state it:

$bp->readImageBlob($content, 'SGI:blob');

That is a hard pin, not a hint. BlobToImage() sniffs only when the format is unset
(magick/blob.c:359-360), and an explicit FORMAT: prefix sets affirm in SetImageInfo()
(magick/image.c:2945), which returns before the "determine the image format from the first few
bytes" block at :2976. Verified against tag 6.9.12-98. No new Imagick API and no version floor.

Scope is small. There are three Imagick read paths in the whole repo —
Bitmap::getResizedPreview(), SVG::getThumbnail() and Office::getThumbnail() (which already
reads a file it produced itself) — plus one format declaration per Bitmap subclass. Roughly 15-20
lines across 11 files.

Two things worth watching:

• Map MIME type → coder, not provider class → coder. Heic serves both image/heic and
  image/heif, and Font serves application/font-sfnt and application/x-font, so a single
  constant per class forces a wrong guess for one of them. Note that coders/heic.c registers
  HEIC, HEIF and AVIF as three separate coders, so an AVIF-branded file served by the Heic
  provider is the one case I'd want a real test sample for.
• Subimage selection. Office::getThumbnail() passes [0], so a pinned filename becomes
  PDF:/tmp/x.pdf[0]. Frame parsing happens in the same SetImageInfo path, but it deserves a test.

Suggested tests in tests/lib/Preview/: a "pinned format still decodes" case per provider, plus a
negative case asserting that content of one format, under an extension mapping to a different
provider, no longer decodes.

The same change would need to follow on the 10.x line afterwards — no need to touch #41828 until the
v11 approach is agreed here.

[jvillafanez]

Code looks fine. I Assume the tests fail because of the PHP version (OC10 runs with PHP 7.4 not 8.3)

[phil-davis]

https://github.com/owncloud/core/actions/runs/35783629819/job/107115884062?pr=41827

Err:8 mirror+file:/etc/apt/apt-mirrors.txt noble-updates/main amd64 libgs-common all 10.02.1~dfsg1-0ubuntu7.8
  404  Not Found [IP: 52.147.219.192 80]
Ign:9 https://security.ubuntu.com/ubuntu noble-updates/main amd64 libgs10-common all 10.02.1~dfsg1-0ubuntu7.8
Err:9 mirror+file:/etc/apt/apt-mirrors.txt noble-updates/main amd64 libgs10-common all 10.02.1~dfsg1-0ubuntu7.8
  404  Not Found [IP: 52.147.219.192 80]
Ign:14 https://security.ubuntu.com/ubuntu noble-updates/main amd64 libgs10 amd64 10.02.1~dfsg1-0ubuntu7.8
Err:14 mirror+file:/etc/apt/apt-mirrors.txt noble-updates/main amd64 libgs10 amd64 10.02.1~dfsg1-0ubuntu7.8
  404  Not Found [IP: 52.147.219.192 80]
Ign:15 https://security.ubuntu.com/ubuntu noble-updates/main amd64 ghostscript amd64 10.02.1~dfsg1-0ubuntu7.8
Err:15 mirror+file:/etc/apt/apt-mirrors.txt noble-updates/main amd64 ghostscript amd64 10.02.1~dfsg1-0ubuntu7.8
  404  Not Found [IP: 52.147.219.192 80]
E: Failed to fetch mirror+file:/etc/apt/apt-mirrors.txt/pool/main/g/ghostscript/libgs-common_10.02.1%7edfsg1-0ubuntu7.8_all.deb  404  Not Found [IP: 52.147.219.192 80]
Fetched 20.6 MB in 2s (13.0 MB/s)
E: Failed to fetch mirror+file:/etc/apt/apt-mirrors.txt/pool/main/g/ghostscript/libgs10-common_10.02.1%7edfsg1-0ubuntu7.8_all.deb  404  Not Found [IP: 52.147.219.192 80]
E: Failed to fetch mirror+file:/etc/apt/apt-mirrors.txt/pool/main/g/ghostscript/libgs10_10.02.1%7edfsg1-0ubuntu7.8_amd64.deb  404  Not Found [IP: 52.147.219.192 80]
E: Failed to fetch mirror+file:/etc/apt/apt-mirrors.txt/pool/main/g/ghostscript/ghostscript_10.02.1%7edfsg1-0ubuntu7.8_amd64.deb  404  Not Found [IP: 52.147.219.192 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

I restarted the workflow, and it had these same errors.
"something" (tm) is wrong with the infrastructure that provides apt ?

[phil-davis]

actions/runner-images#7452

This is not a new thing. There are plenty of complaints about http://azure.archive.ubuntu.com and that IP address 52.147.219.192

[oc-tmueller]

actions/runner-images#7452

This is not a new thing. There are plenty of complaints about http://azure.archive.ubuntu.com and that IP address 52.147.219.192

fix coming in ....

[kw-fscheuer]

Reviewed the six commits over 13c6163857, read-only against the branch.

The design is sound and I want to be clear about that up front: rejecting text-shaped content before ImageMagick and pinning the coder per provider gives two independent layers, and the comments explaining each decision are unusually good — particularly the one on getImagickFormat() setting out why $mimeType comes from $file->getMimeType() rather than the selection type, and why returning a constant is the right answer for trashbin previews. I traced the fail-open case below through both layers and the pin does hold the line: MVG content routed to the TIFF provider still dies in the TIFF coder. That is the defence-in-depth working as intended.

Three things I would want fixed before this merges.

1. The mime gate fails open — lib/private/Files/Type/Detection.php:264-277

isDangerousToDecode() (Bitmap.php:164) delegates to Detection::detectString(), which returns finfo_buffer() verbatim at line 267. That is typed string|false. When it returns false, explode(';', false, 2)[0] coerces to '', both strpos() checks miss, in_array('', [...], true) is false — and the content is admitted.

The else branch is the larger version of the same problem. With no ext-fileinfo it writes a temp file and calls $this->detect($tmpFile), which is extension-first; a temp file with no meaningful extension falls through to application/octet-stream unless the file binary happens to be installed. On such a build the OC10-164 gate admits everything. That branch also truncates to 8024 bytes (line 271), so even the file-binary path can be padded past.

Suggest an explicit fail-closed branch in isDangerousToDecode() — anything that is not a non-empty string is dangerous. That is cheaper than hardening detectString(), whose other callers expect the current behaviour.

2. finfo_open() is unchecked — same function, line 266

finfo_open(FILEINFO_MIME) returns false on a missing or corrupt magic database and goes straight into finfo_buffer(false, $data), which is a TypeError under PHP 8. TypeError is an \Error, so it walks past the catch (\Exception) in Bitmap::getThumbnail() and every bitmap preview becomes a 500 rather than degrading to a media-type icon.

Worth flagging because b5d51e6 in this same PR added the (string) cast on getMimeType() for precisely this hazard, with a comment explaining it — and the new code path then reintroduces it.

3. SVG::getThumbnail() does not check fopen() — lib/private/Preview/SVG.php:48

$stream = $file->fopen('r') at line 48, then stream_get_contents($stream) at 49, with no === false guard. Same TypeError → 500 path that Bitmap.php:49 now guards explicitly, with a comment saying exactly why. Same PR, one file brought up to standard and the other missed. The fclose() at line 53 is also outside any finally, so a throw between 48 and 53 leaks the handle — Bitmap.php gets that right too.

Non-blocking

• ImagickFactory::create($path) sets svg:sanitize/svg:embed/svg:decode after new Imagick($files) has already decoded, so the path-taking overload gets none of the hardening. Office.php is the only caller that passes a path, and the new comment there presents it as the hardened route. The 'PDF:' prefix pin does work, since that is constructor-level, and it is LibreOffice's own output — so no impact here. But the API invites the mistake: construct empty then readImage(), or drop the overload.
• SanitizeTest's new class-level @requires extension imagick contradicts the method comment directly below it, which argues against a coder guard so that a reduced build cannot silently skip the OC10-164 regression assertions. Every assertion in that class fires before Imagick is touched. The annotation belongs on CoderPinningTest only.
• assertImage() (tests/lib/TestCase.php:559) and tests/lib/Preview/white-32x32.png are left with no callers or references.
• detectString() runs over the whole file, up to preview_max_filesize_image (50 MB default), on every cache-miss preview. The non-finfo branch already truncates to 8024 bytes, which yields the same verdict for every type in the deny-list.
• The RuntimeException thrown at Bitmap.php:108 is logged at line 66 as ImageMagick says: Refusing to decode text-based content.... An operator grepping for attempted OC10-164 exploitation cannot distinguish a blocked MVG upload from a corrupt TIFF. A separate catch, or a distinct marker, would make the gate attributable.
• Scope: two changelogs, an unchangelogged 500 fix, and the PDFTest/SVGTest gate rewrite, against AGENTS.md:95,97. Probably not worth splitting now given the shared test suite, but noting it.

One residual worth a changelog sentence

41834 correctly scopes its Ghostscript claim to "any other bitmap provider". The direct route does stay open: provider selection is request-steerable — as the getImagickFormat() comment itself documents for apps/dav — and PDF::getImagickFormat() returns 'PDF' unconditionally, so ?mimeType=application/pdf on an arbitrary file pins its bytes to the PDF coder. Not a regression, since content sniffing did the same before, and the stock Debian/Ubuntu policy denies PDF/PS/EPS. A sentence setting that expectation would help.

Relatedly, this PR establishes that policy.xml is the process-wide control but neither ships one nor documents it as a deployment requirement. Any future code constructing an Imagick outside ImagickFactory reopens the class.

Two I could not confirm

Flagging rather than asserting, both cheap to make defensive regardless:

1. Whether Imagick::setFormat() can return false without throwing on a build that does not register the coder — which would make the unchecked return value in getResizedPreview() fall back to the content sniffing the pin exists to prevent.
2. Whether CoderPinningTest::requireDecodableFixture()'s catch (\ImagickException) misses the warning-severity condition that Provider::requireDecodableFixtureFile() deliberately catches as \Throwable — which would hard-fail the PDF/EPS/AI cases under failOnWarning="true" on policy-restricted distros, where they should skip.

[oc-tmueller]

3. SVG::getThumbnail() does not check fopen() — lib/private/Preview/SVG.php:48

already taken care of in https://github.com/owncloud/core/pull/41855/changes#diff-a55bd399feae16fe962bcdbcf764898adac00073a296a287d71b9c94b0815988

[oc-tmueller]

Addressed below. I rebased onto master first, which resolves finding 3 on its own.

Blocking findings

1 + 2 — the gate failing open, and finfo_open() unchecked. Both fixed in
Detection::detectString() rather than in isDangerousToDecode(). detectString() is
documented as returning a string and isDangerousToDecode() is its only production
caller, so fixing the contract at source covers both conditions and leaves nothing for the
gate to re-check: a false from finfo_open() and a non-string or empty finfo_buffer()
both fall back to application/octet-stream. The function_exists() guard also tested
finfo_file(), which that branch never calls — it now tests finfo_buffer().

I confirmed the mechanism before fixing rather than from the signature:
finfo_buffer(false, 'x') is TypeError: Argument #1 ($finfo) must be of type finfo, false given on 8.3, and a failing finfo_open() raises three warnings first. The regression test
drives it through MAGIC, which libmagic reads at finfo_open() time, and asserts that
precondition so it fails loudly rather than going quiet on a build that ignores MAGIC.

Auditing that function turned up two more instances of the same hazard on the path your
finding routes into, both fixed alongside:

• the no-fileinfo branch wrote a temp file without checking getTemporaryFile() — which
  returns false on an unwritable temp dir — or fopen(). fopen(false, …) is a
  ValueError on PHP 8.
• detect() then falls back to the file binary, and OC_Helper::canExecute() only
  establishes that the binary exists, not that we may start a process. popen is a common
  disable_functions entry, and on PHP 8 a disabled function is undefined, so the call
  raises Error: Call to undefined function popen(); popen() returning false on a failed
  fork likewise makes fgets()/pclose() raise TypeError.

Both are \Error rather than \Exception, so both were 500s rather than a media-type icon —
the same shape as your finding 2, two and three frames down. Worth noting because these only
matter now: nothing in core called detectString() before this PR, so that whole branch was
unreachable from a request until the gate started using it.

The part I have deliberately not closed is the no-ext-fileinfo fail-open you fold into
finding 1. It is documented at isDangerousToDecode() instead. ext-fileinfo is required
by composer.json, but that binds only at composer-install time and release tarballs ship
a pre-built lib/composer: OC_Util::checkServer()'s hard dependency list does not include
it, and OC_Util::fileInfoLoaded() only raises an admin-panel recommendation ("we strongly
recommend"). Such an install boots and is supported, so failing closed would cost it every
bitmap preview — tif, psd, sgi, heic, ai, pdf, eps. Since the coder pin still holds there,
as your own TIFF/MVG trace shows, I recorded it as a bounded limitation rather than trading
those previews away. Glad to raise it as its own issue if you would rather see it tracked.

Note that findings 1 and 2 cannot arise on that configuration anyway — both live in the
finfo branch, which is not taken when fileinfo is absent.

3 — SVG::getThumbnail()'s unguarded fopen(). Fixed independently in #41855, which
landed on master while this was in review, in exactly the shape you describe:
!is_resource() plus fclose() in a finally. The rebase picked it up, so nothing is left
to do here, and I checked that both sides survived it intact.

Non-blocking, taken

• ImagickFactory::create($path). Fixed — constructed empty, options applied, then
  readImage(). Verified in a container rather than reasoned about, since the constructor
  pin is load-bearing for Office: PDF:<path>[0] yields identical geometry and identical
  output bytes either way, a PNG pinned to the PDF coder is still rejected either way, and
  readImage() does not pin the wand's output format the way setFormat() does — so
  Office.php still needs only setImageFormat('jpg') and its comment stays accurate. The
  parameter is narrowed from mixed to ?string; the array form Imagick accepts has never
  had a caller.
• SanitizeTest's @requires extension imagick. Removed — it does contradict the
  comment below it, and all ten cases run without it, since the gate rejects every payload
  before ImagickFactory::create().
• Orphaned assertImage() and white-32x32.png. Both deleted.
• The residual changelog sentence. Added to changelog/unreleased/41834.

Non-blocking, not taken

• The log marker separating a blocked payload from a corrupt TIFF, and truncating the
  sniff to 8 KB. Both are reasonable; both are deferred rather than folded into a security
  fix, as a maintainer call.
• policy.xml as a documented deployment requirement. The image side is fix: harden ImageMagick policy and install rsvg-convert (OC10-164) owncloud-docker/php#309;
  the documentation belongs in docs rather than in this PR.
• Scope, AGENTS.md:95,97. Agreed, and taking your own read that splitting is not worth
  it given the shared test suite.

The two you could not confirm

1 — can setFormat() return false without throwing? No. I probed every coder absent
from owncloudci/php:8.3 — JXL, DJVU, FPX, EXR, FLIF, SVG, HEIF, plus a nonsense name — and
each raises ImagickException: Unable to set format; registered coders return true. So the
unchecked return cannot silently degrade to the content sniffing the pin prevents: the
fail-closed behaviour you wanted already happens via the exception, which
Bitmap::getResizedPreview() deliberately does not catch. The one edge this surfaced is that
setFormat('') returns true — unreachable here, since all eight getImagickFormat()
implementations return non-empty constants and the method is typed string.

2 — requireDecodableFixture() vs requireDecodableFixtureFile(). The premise does not
hold at the current head: both catch \Exception — not \ImagickException, not \Throwable
(CoderPinningTest.php:97, Provider.php:109). Each carries a comment on exactly your
point: \Exception because PHPUnit converts warning-severity delegate and policy conditions
into PHPUnit\Framework\Error\Warning, which reaches \Exception via
PHPUnit\Framework\Exception; and not \Throwable, so an \Error still fails rather than
becoming a green skip. The PDF/EPS/AI cases therefore skip rather than hard-fail on a
policy-restricted distro, which is the outcome you were after.

One further thing your review prompted me to check, and then correct: the Postscript
provider justified pinning EPS on it sharing ReadPSImage() with PS. That sharing is
conditional, so rather than leave an unverified internals claim I replaced it with a measured
one — plain PostScript and EPSF-tagged content, both declaring a bounding box smaller than
the page, render to identical geometry read unpinned, pinned EPS and pinned PS.

Locally re-run on owncloudci/php:8.3: tests/lib/Preview/ 86 tests with only the
pre-existing Movie/Office/SVG skips, tests/lib/Files/Type/ 12 tests, php-cs-fixer clean,
and php -l under 7.4 so #41828 can cherry-pick without syntax changes.

[kw-fscheuer]

Re-reviewed at cb4196ac, read-only against the branch and against ImageMagick6 upstream.
Approving. OC10-164 is closed, and all three of my blocking findings are fixed in code rather
than only answered.

What I checked rather than took on trust

The reported vector is dead twice over. Bitmap::getResizedPreview() no longer
sanitizes-then-falls-back — the raw-bytes path is gone — and text/SVG/XML/MVG-sniffed content
is rejected before ImagickFactory::create() is ever reached:

core/lib/private/Preview/Bitmap.php

Lines 109 to 112 in cb4196a

	if ($this->isDangerousToDecode($content)) {
	throw new \RuntimeException('Refusing to decode text-based content for a bitmap preview');
	}

Independently of that gate, the payload is pinned to the provider's own coder:

core/lib/private/Preview/Bitmap.php

Lines 125 to 128 in cb4196a

	# the content-sniffing this pin exists to prevent.
	$bp->setFormat($this->getImagickFormat($mimeType));
	$bp->readImageBlob($content);

SanitizeTest now asserts false for a malformed SVG carrying an MSL xlink:href, a raw MVG
script and a well-formed SVG, and assertPayloadIsDeniedByTheMimeGate() asserts the
precondition, so a build whose libmagic classifies the payload differently fails loudly instead
of going quiet. The headerless-PostScript case is the right addition — it is the one payload the
gate has to catch unaided, because for PDF and Postscript the pin is not a second layer.

Findings 1 and 2 are fixed here:

core/lib/private/Files/Type/Detection.php

Lines 282 to 294 in cb4196a

	// missing bitmap preview into a 500 in OC\Preview\Bitmap::getThumbnail().
	$finfo = @\finfo_open(FILEINFO_MIME);
	if ($finfo === false) {
	return 'application/octet-stream';
	}
	// finfo_buffer() is typed string|false. An unusable return has to become the
	// fallback rather than reach a caller, because this method is documented as
	// returning a string and OC\Preview\Bitmap compares the result against a
	// deny-list of media types it refuses to decode - '' matches no entry there
	// and would admit the very content the list exists to reject.
	$mimeType = \finfo_buffer($finfo, $data);
	return \is_string($mimeType) && $mimeType !== '' ? $mimeType : 'application/octet-stream';

Your placement is better than mine. I said detectString() had other callers expecting the
current behaviour; it does not — the interface, the new gate and two test files are the whole
set — so fixing the contract at source was the right call, not the more expensive one.

Finding 3 arrived with the rebase from #41855, and both the is_resource() guard and the
fclose() in finally are present:

core/lib/private/Preview/SVG.php

Lines 47 to 67 in cb4196a

	$stream = $file->fopen('r');
	if (!\is_resource($stream)) {
	// stream_get_contents() below would raise a TypeError, which is an \Error and
	// so would escape the handler underneath rather than degrade to no preview.
	// Not a === false check: View::fopen() returns null for a path
	// isForbiddenFileOrDir() rejects and for one Filesystem::resolvePath() finds
	// no storage for, and that reaches stream_get_contents() just as badly.
	\OCP\Util::writeLog('core', 'Could not open ' . $file->getPath() . ' for a preview', \OCP\Util::ERROR);
	return false;
	}
	try {
	$content = \stream_get_contents($stream);
	} finally {
	// the read itself can throw from the wrapper stack - the encryption module
	// does, on a corrupt or missing key - and that is caught below, so without
	// this the descriptor and the view's shared lock would both be held on
	\fclose($stream);
	}

Three things I checked because they would have been quiet failures: all eight Bitmap
subclasses implement getImagickFormat(), so there is no abstract-method gap; both
ImagickFactory::create() call sites pass a string or nothing, so narrowing to ?string breaks
nothing; and setFormat('png') next to setImageFormat('png') is load-bearing for the
(string)$bp cast at Bitmap.php:79, which testPinnedDecodeReturnsPngAndNotThePinnedInputFormat()
now guards. After this PR no new Imagick survives outside ImagickFactory, which is what makes
this a fix for the class rather than for the instance.

One new finding — not a blocker, and I am not holding the merge for it

The changelog tells operators that "the PDF, PostScript and EPS coders are the ones a
distribution's ImageMagick policy denies by default":

core/changelog/unreleased/41834

Lines 41 to 45 in cb4196a

	they are. This is not a change - content sniffing reached the same coder before -
	and the PDF, PostScript and EPS coders are the ones a distribution's ImageMagick
	policy denies by default. Deployments that enable those coders should keep that
	policy as the control, because it applies process-wide rather than per provider.

That list is one short, and this PR's own tests say so: CoderPinningTest excludes PDF,
Postscript and Illustrator from providesForeignProviders() as the Ghostscript-backed
providers, and notes that the AI coder "is a Ghostscript alias for the PDF one".

For policy purposes it is not an alias. coders/pdf.c registers AI as its own entry, with
ReadPDFImage as the decoder and magick_module set to "PDF":

https://github.com/ImageMagick/ImageMagick6/blob/45439b3fd7ea3e12bfbb94269efe8af51cf78367/coders/pdf.c#L796-L807

and ReadImage() authorizes the coder domain against magick_info->name, passing the module
only to the module domain:

https://github.com/ImageMagick/ImageMagick6/blob/45439b3fd7ea3e12bfbb94269efe8af51cf78367/magick/constitute.c#L565-L568

https://github.com/ImageMagick/ImageMagick6/blob/45439b3fd7ea3e12bfbb94269efe8af51cf78367/magick/constitute.c#L423-L432

So <policy domain="coder" rights="none" pattern="PDF"/> — the form the stock Debian/Ubuntu
policy uses — does not cover a read pinned to AI. A domain="module" deny would.

The consequence is narrow but it points the wrong way: read unpinned, .ai content carrying
%!PS-Adobe sniffed as PS and was denied by that policy; pinned, it decodes as AI and is not.
It needs OC\Preview\Illustrator to be explicitly enabled, and that provider is in neither the
hardcoded default (PreviewManager.php:266-281) nor config.sample.php, so this is a hardening
regression for an opt-in provider rather than anything reachable on a stock install. That is why
this is a note and not a change request.

Adding AI to that changelog sentence covers the operator side. Whether the pin should also be
reflected in a recommended policy.xml is a docs question rather than one for this PR. Tracked
on our side.

Minor, take or leave

• Bitmap.php:59 still reads "Creates \Imagick object from bitmap or vector file". Vector
  content is precisely what the code below it now refuses.
• Bitmap.php:172-174 calls the coder pin "the only remaining layer" where detection is
  unavailable. True for six providers; for PDF and Postscript it is not a layer at all, as
  SanitizeTest's own comment on the headerless-PostScript payload sets out.
• Detection.php:277 says "suppressed like finfo_file() below". That call is above, at
  :224-227, and what guards it against a false finfo_open() is the and-chain
  short-circuit, not the @.
• SVGTest's === 0 is the right change for the wrong reason: queryFormats() globs, and
  'SVG' carries no wildcard, so it never matched SVGZ or MSVG.

None of that changes the verdict. The two "could not confirm" items are both answered by
measurement, which is the right way to have closed them. Ship it.