Set `VIPS_BLOCK_UNTRUSTED` by default

[jcupitt]

Many libvips binaries ship with a range of poorly tested loaders, and these are all enabled by default.

If you are dealing with untrusted data (as most intervention users probably will be), it's best to disable these by default. An easy way to do this is to set the VIPS_BLOCK_UNTRUSTED env var on startup, and give users some way to reenable specific wonky loaders if they have to.

https://www.libvips.org/API/current/VipsOperation.html#vips-operation-block-set

[olivervogel]

That's a good suggestion. Will be integrated.

[olivervogel]

I have noticed that this causes, among other things, that svgload_buffer() can no longer be used and thus all "draw” operations no longer work because the shapes are defined in svg format. Is there a way to avoid this by using a different loader or any other way or is SVG simply “unsafe”?

image-driver-vips/src/Driver.php

Lines 128 to 137 in 90c8cc2

	$svg = '<svg viewBox="0 0 ' . $width . ' ' . $height . '" xmlns="http://www.w3.org/2000/svg">' .
	'<' . $shape . ' ' . $xmlAttributes . ' />' .
	'</svg>';
	try {
	return VipsImage::svgload_buffer($svg);
	} catch (VipsException $e) {
	throw new RuntimeException('Could not create shape: ' . $e->getMessage(), previous: $e);
	}

[jcupitt]

From memory, it's tagged as untrusted because we've not been fuzzing it and support is not included in the web binary we distribute. Parts of librsvg used to be GPL as well, so that also prevented binary distribution. Though I think this is now fixed for most versions (I think?).

You're right, we should expose vips_block_untrusted_set() so that intervention can have more granular control. It'll need a new php-vips though, so maybe park this issue for now.

libvips 8.16 has a new way to draw shapes with signed distance fields:

https://www.libvips.org/2024/10/10/What's-new-in-8.16.html

They are must faster and need less memory than SVG, though they won't work with your createShape() API, sadly.

[olivervogel]

Depends on #61