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 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.