The problem is they use binary versions of core tools like cryptsetup in their source tree, vs compiling them at build time.
This leaves the door open to supply-chain attacks. I.E. a PR with a bad cryptsetup binary, or an attack on crypt that makes its way downstream with no way to audit. This is how huge software distributions make their way to Wikipedia in a bad way: https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor
The solution is the build those binaries at build time, which a fork is working on.
The advantage of Ventoy is its ability to work in any environment and handle 99% of ISOs. Compiling the binaries at build time requires a mature development environment to be able to build these utilities… Your exponentially increasing the size and complexity of the project to solve a relatively minor security issue.
Ventoy is not the only way to create a bootable drive… If you don’t trust the blobs then don’t run the software.
Forking ventoy to add the complexity of building these utilities is only going to be available for *nix base environments so Windows users are pretty much shit out of luck. Your exponentially increasing the size of the project, it’s complexity, and simultaneously significantly narrowing its usability…
I said it before and I’ll say it again it’s such a bad fucking argument. It’s not mature software. It’s a literal confluence of hacks… And if you’re not comfortable with using it then don’t use it. It really is a huge security risk. But advocating that nobody use it is such stupid fucking thing.
Advocate that people understand the risks of using it but to just run around and scream about how nobody should be using it for any reason whatsoever until the maintainer closes the security hole that makes it run is pretty stupid.
In February 2024, a malicious backdoor was introduced to the Linux build of the xz utility within the liblzma library in versions 5.6.0 and 5.6.1 by an account using the name “Jia Tan”.[b][4] The backdoor gives an attacker who possesses a specific Ed448 private key remote code execution through OpenSSH on the affected Linux system. The issue has been given the Common Vulnerabilities and Exposures number CVE-2024-3094 and has been assigned a CVSS score of 10.0, the highest possible score.[5]
Binary supply-chain attacks are not “minor security issues”. There is a reason many companies will not allow admins to use Ventoy.
I like Ventoy, it’s a fantastic project. I like that the author is transparent about where they won’t be spending their time. You can like a project, and recognize it’s flaws at the same time.
A contributor building a PR to solve the build concerns is not a bad thing, it’s to be celebrated. Even a short-term solution of having the build script pull the binaries from a release and checksum them would alleviate a lot of that concern. And the Windows vs Nix item would be alleviated by the GitHub build ENV. Binary releases isn’t the problem, it’s binary in the source. This is about audits and traceability more than the build itself.
Not having a security first posture on these kinds of attacks is how the xz event happened, and I would hate to see that happen to Ventoy. I look forward to contributors helping the author out.
The build environment was not clean to start, which is why a contributor is working to correct that.
You could also have the build scripts that run on GitHub pull the binary releases directly from their original release locations at build time, vs a file that an individual can modify in the source tree. This isn’t as good as building from source, but it’s better than nothing.
The problem with Ventoy isn’t the ISOs.
The problem is they use binary versions of core tools like
cryptsetupin their source tree, vs compiling them at build time.This leaves the door open to supply-chain attacks. I.E. a PR with a bad
cryptsetupbinary, or an attack on crypt that makes its way downstream with no way to audit. This is how huge software distributions make their way to Wikipedia in a bad way: https://en.m.wikipedia.org/wiki/XZ_Utils_backdoorThe solution is the build those binaries at build time, which a fork is working on.
@[email protected]
Interesting! & longpanda*
Explains y’all paranoid and keeps using those binaries? Says “sorry I do this free and that would take forever”?
*
To clarify, asking if there has ever been an official developer response/debate on this.
The advantage of Ventoy is its ability to work in any environment and handle 99% of ISOs. Compiling the binaries at build time requires a mature development environment to be able to build these utilities… Your exponentially increasing the size and complexity of the project to solve a relatively minor security issue.
Ventoy is not the only way to create a bootable drive… If you don’t trust the blobs then don’t run the software.
Forking ventoy to add the complexity of building these utilities is only going to be available for *nix base environments so Windows users are pretty much shit out of luck. Your exponentially increasing the size of the project, it’s complexity, and simultaneously significantly narrowing its usability…
I said it before and I’ll say it again it’s such a bad fucking argument. It’s not mature software. It’s a literal confluence of hacks… And if you’re not comfortable with using it then don’t use it. It really is a huge security risk. But advocating that nobody use it is such stupid fucking thing.
Advocate that people understand the risks of using it but to just run around and scream about how nobody should be using it for any reason whatsoever until the maintainer closes the security hole that makes it run is pretty stupid.
You:
Wikipedia:
Binary supply-chain attacks are not “minor security issues”. There is a reason many companies will not allow admins to use Ventoy.
I like Ventoy, it’s a fantastic project. I like that the author is transparent about where they won’t be spending their time. You can like a project, and recognize it’s flaws at the same time.
A contributor building a PR to solve the build concerns is not a bad thing, it’s to be celebrated. Even a short-term solution of having the build script pull the binaries from a release and checksum them would alleviate a lot of that concern. And the Windows vs Nix item would be alleviated by the GitHub build ENV. Binary releases isn’t the problem, it’s binary in the source. This is about audits and traceability more than the build itself.
Not having a security first posture on these kinds of attacks is how the
xzevent happened, and I would hate to see that happen to Ventoy. I look forward to contributors helping the author out.Couldn’t you just compile those dependencies yourself and use your own blobs then?
Yes, but…
The build environment was not clean to start, which is why a contributor is working to correct that.
You could also have the build scripts that run on GitHub pull the binary releases directly from their original release locations at build time, vs a file that an individual can modify in the source tree. This isn’t as good as building from source, but it’s better than nothing.