Most basic image manipulation can be performed using only the standard library packages, if your language includes such (PHP's bundled `libgd2` fork / Golang's `image` package / Qt QImage+QPixMap ). For Python `pillow` is popular.
From a security standpoint, wouldn't it be better to rely on PHP (first)? Are you more or less likely to get RCE from PHP or ImageMagick? I'd say PHP has had a lot more eyes on it, security wise.
> From a security standpoint, wouldn't it be better to rely on PHP (first)?
You're joking, right? Popping PHP boxes is script kiddie 101. You might argue that "bad developers make insecure software" but when you're given a toolbox with nothing but oddly shaped hammers it's very hard to make a house.
That's rarely PHP failing but whatever framework/CMS is used. That's like saying C++ is inherently insecure because there exists a lot of software written in C++ with security holes.
Did you read the second sentence I wrote? Just because you can write safe code in a language that tries to make you footgun at every turn, doesn't mean that language is a good language. Pick a language that doesn't suffer from crippling security issues (which, sure, you can workaround -- but why use a language that requires workarounds to get security?).
We started Imageflow (https://www.imageflow.io ) in C to design the C ABI for interop with all the host languages, but we're swapping out components for Rust every time it's possible/practical.
Or, when saving to file for imagemagic, have it be a random temp name, with the correct file extension, read in the result, and only serve it as the original name when downloaded, if it fits the use case.
PHP does not use imagick, but a (forked) libgd2 by default (some distros patch php to use the distro libgd). Imagick is only available if you install a C PHP extension providing an imagick interface.
