From what I understand ImageMagick's vulnerability management involves updating to newer versions, so this is specifically about distributions that don't. Ubuntu chooses to distribute older versions with their own patches, but require Pro for you to get them.

With that said, the mentioned vulnerability is an odd one. A CVE published in 2023 with a CVE number for 2022 for a bug that was found and fixed in 2020. The bug in question is a memory leak when passing -help.[1]

[1]: https://github.com/ImageMagick/ImageMagick/issues/2889

What does this have to do with ImageMagick? They don't control the versions packaged by Canonical [0]. The bug you referenced is fixed in upstream, which you can access for free on GitHub.

Ubuntu users on 22.04 LTS or later are also unaffected, because the release came with a version that was already patched [1]. If you upgrade to a newer Ubuntu release, there is no need to pay for ESM.

Your comment makes it sound like the ImageMagick developers want money specifically from Ubuntu users to reveive security patches, which is not true.

[0] https://github.com/ImageMagick/ImageMagick/discussions/6805#...

[1] https://ubuntu.com/security/CVE-2022-48541

Edited to add some links.

You appear to be leaping to the wrong conclusion. The problem is Canonical charging money for security updates. CentOS, Alma, Rocky, Fedora, Debian, openSUSE, Arch, and 300+ other Linux distros don't charge money for security updates either. The moral of the story is "Don't use enshitifying corporate Linux distros run by crazy people."

This still has nothing to do with the ImageMagick developers, which the original comment implies: "Compare [sic] to codesign, vulnerability management is more concerning."

You are free to criticize Canonical for their business model, but that seems off-topic to me right now.

The problem of Canonical charging money for security updates is off-topic when we're discussing ImageMagick's code-signing troubles on Windows.

That's your opinion, and I don't care for your attempts to shut people down. Kindly control people on the rest of the internet. :peace:

nix and habitat are alternative ways to bring user-space additions outside of a distro's package management in a repeatable manner. Otherwise, one has to make their own packages and run their own CI/CD package builders. I did this for Erlang, Elixir, and rebar3 since the corporate consultants who ran a YUM repo appeared to have stopped providing such for CentOS 9 stream. I think it's less painful to either standardize on 1 OS and add custom RPM/DEB packages, or ignore what the OS provides and vendor all user-space dependencies to an isolated stable path with a different packaging/build system.