Here’s my personal bottom line:
Ventoy is a tool that can be useful, but the build process is so convoluted as to make it nearly impossible to verify that all of the dependencies are uncompromised.
What is becoming more important to understand is that there needs to be verifiable evidence that a software build is uncompromised, and a way to track back a build to determine if a required subcomponent has been compromised, that this has been addressed.
Ventoy has numerous dependencies, not the least of which is being built on CentOS 7.8 (according to the author’s own build instructions on github), which has been out of support since June 30, 2024. That means that it’s being built on an operating system that hasn’t had any security updates in nearly 2 years.
So there’s no way to know if that developer’s system has been compromised by any number of critical kernel CVEs that have come out in the last two years, along with updates and fixes to the software development tools themselves.
It includes a large list of precompiled binaries (all of which are open source, as far as I can tell) along with checksums. Some of those are no longer actively developed (like syslinux).
One tool included is a tool called dmsetup, which is extracted from a tool called DragonFlyBSD; that BSD variant (as far as I can tell, that’s what it is) was released in 2020, but a more recent version is available - but it would be better to have included a reference to the dmsetup tool’s source rather than “extract this binary blob from an ISO that is no longer considered current”.
This makes it hard to verify the provenance of the code that’s used, or to inspect it for potential security issues or flaws.
Now, add to that the history of Ventoy modifying the installer ‘linux’ command-line to inject its own stuff into the installation process. This violates the integrity of the openSUSE image in ways that are difficult to tell. From what I understand, this has been changed, but doing that in the first place constitutes (to me) a breach of trust that needs to be rebuild - and having an incredibly difficult to follow build process doesn’t do anything to rebuild any sort of trust.
Now, as to the statement that “openSUSE” (a) the developer isn’t specifying what version of openSUSE (or even which distribution - was Tumbleweed tested (and if so, which specific release), Leap (and which version if Leap), Kalpa, Slowroll, Aeon, …?) was tested, and (b) “test support” isn’t well defined, but I would read that to mean “it boots”. Not that it installs correctly, that it works correctly, or anything beyond that.
I seriously doubt that the developer ran 275 test suites to ensure every aspect of every ‘tested’ OS worked as if it were installed from official media. That would be a massive amount of work to do.
The fact of the matter is that we have no idea what constitutes the “Ventoy test” that is performed, because the developer does not appear to have documented that anywhere.
For me, personally, I prefer to trust a development process and chain that is easily reproducible, with code that is not extracted from ISOs, but rather is built from source that I (or others) can easily find and audit. While Ventoy says it is released under GPL v3+, the inclusion of directly used or libraries or binaries makes reproducible builds nearly impossible to validate against the ‘official’ binaries.