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 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 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.
Binary supply-chain attacks are not “minor security issues”.
Yes they are. The binaries for Ventoy aren’t even updated from release to release. It’s not even evident how old they are. So crying about an attack that only matters if these binaries are bleeding edge is absolutely a minor issue. I don’t even understand how someone of sound mind and body could possibly believe otherwise.
Not having a security first posture on these kinds of attacks is how the xz event happened
No one is making the argument that security doesn’t matter. No one is pushing the idea that Ventoy is secure. I’m saying singularly and only that a supply chain attack is just about the dumbest goddamn angle possible to bitch about Ventoy because I could argue that Ventoy would be more vulnerable than it is now to a supply chain attack if the binary blobs are built and updated every time you build a bootable drive. It’s just a truly fucking insane argument that shows a lack of understanding of what a supply chain attack is. The built binaries may be vulnerable and it’s difficult to prove if they are or not, but if you update the binaries all the time they’re more (attack surface is larger) than if they’re only updated when absolutely necessary…
It’s just plain a poor argument and I’m tired of every armchair expert pretending that its not. People in high security environments aren’t using Ventoy. It’s just such a ridiculous argument.
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]
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.
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.Yes they are. The binaries for Ventoy aren’t even updated from release to release. It’s not even evident how old they are. So crying about an attack that only matters if these binaries are bleeding edge is absolutely a minor issue. I don’t even understand how someone of sound mind and body could possibly believe otherwise.
No one is making the argument that security doesn’t matter. No one is pushing the idea that Ventoy is secure. I’m saying singularly and only that a supply chain attack is just about the dumbest goddamn angle possible to bitch about Ventoy because I could argue that Ventoy would be more vulnerable than it is now to a supply chain attack if the binary blobs are built and updated every time you build a bootable drive. It’s just a truly fucking insane argument that shows a lack of understanding of what a supply chain attack is. The built binaries may be vulnerable and it’s difficult to prove if they are or not, but if you update the binaries all the time they’re more (attack surface is larger) than if they’re only updated when absolutely necessary…
It’s just plain a poor argument and I’m tired of every armchair expert pretending that its not. People in high security environments aren’t using Ventoy. It’s just such a ridiculous argument.