Ventoy: Create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI Files

The lot of (partially scary) binary blobs is still an unsolved issue: https://github.com/ventoy/Ventoy/issues/3224

If anyone is wondering, then there are Ventoy alternatives like IODD [0], but they are not perfect. Usable, but annoying in some aspects.

[0]: https://ounapuu.ee/posts/2025/02/14/iodd-st400-review/

An alternative was offered here: https://news.ycombinator.com/item?id=41959908

https://github.com/thias/glim

does not support Windows

I don't see the linked issue as a valid reason to stop using Ventoy, especially since the repo you linked is for a different piece of software made by the same people. Do we have any evidence of Ventoy itself being in any way malicious?

The rationale for needing a random driver makes some sense. The statement that they found a random build that was signed by some randy is a horrifying prospect.

I am actually happy reading that though. As in it's literally the authors of the tool stating "hey we have a lot of binary blob drivers, what can we do to replace these?". He then audits them and links to build instructions.

As in yeah there's precompiled binaries in this. But it's audited and each binary itself has a link to build instructions. What they are not doing is actually building everything from scratch in their build process. Ok that's a pain to do and i get it. But... i don't see anyone slipping in an unaccounted for binary here right? If every binary itself has a "here's how to build this from scratch" documentation and source it seems ok to me.

All of it is built from source, it's just that the current build process is not easy to audit. The build by definition needs to happen on multiple platforms or cross compiled, a root cert needs to be setup in the windows installer at boot time, and so on.

I agree that this is not an ideal way to boot an ISO, but the general public is unlikely to ever need a multiboot USB stick. I like this project enough to perhaps contribute.

I think it's a valid reason unless you view "this person can't be trusted follow safe practices on Project A so it makes sense to assume they also won't follow safe practices on Project B" as invalid logic.

And crucially, since each blob is from an open source project with build instructions, it seems like you can build Ventoy completely from source if you really want.

From the linked thread

"I have updated a new 1.0.21 release and removed the unused sig driver file. And I also add a README document about the httpdisk driver https://github.com/ventoy/PXE/tree/master"

As in the author responded and removed this and explained why it was in there in the first place.

So Ventoy has all it's code audited and documents every case of a binary blob with the source code and instructions to build the binary blob. iVentoy above did have an issue which was promptly resolved.

It seems to be an extremely trustworthy project. If you want to blacklist them because they once had an issue since corrected fine but it seems waaaaaay over the top to me.

From the linked thread

"I have updated a new 1.0.21 release and removed the unused sig driver file. And I also add a README document about the httpdisk driver https://github.com/ventoy/PXE/tree/master"

So he fixed the issue, noted the use of WKDTestCert and links to it and he also has a post explaining why this happened.

That doesn't seem lackluster or negligent to me?

I don't see the problem with grabbing binary blobs from other trusted projects. Isn't it sufficient just to be able to prove the hashes match what you'd get directly from the origin? If you got your blob from (say) Debian, and their blobs were backdoored, the world has... much bigger problems to worry about. Feels like trying to verify that your pharmacy is making your medication from scratch, lest their supplier had contaminated it.

My concern is that they grabbed some random driver signed by a random person and just assumed it was trustworthy enough to be included in a project. That's not the behavior I associate with how "extremely trustworthy" projects should be run. I understand others may not agree, though. I also understand that this is a different project, but that behavior kinda makes me feel like any project with those people involved shouldn't be viewed as extremely trustworthy. Are they also running randomly grabbed code on the build machines and assuming it's safe to do so?

Someone compared hashes of the sectors of both drivers and they are identical except for the signature.

You don't know what due diligence was done.

The binary blob issue has been brought up since back in 2020. And since then very little real progress has happened from what I can tell.

I am not willing to use the software due to that issue. It just seems suspicious.

I don't, no, but why should I trust the maintainer, and why should the maintainer trust Randy from some random site?

Just to be clear do you understand that all of these are built from source with documentation so you can recreate the binaries yourself?

As in it's completely source buildable with no unknown binaries. They just don't have a single 'build' that pulls all of these in and builds them at once. Instead you're following the build instructions for each part, creating libraries that you then link together at the end. This is due to the pain in the ass of cross-compiling Linux/Windows/UEFI binaries all in the one project. It's pretty reasonable.

Because you intend to run their software? And don't try to tell me you've never ran any proprietary software.

To sibling comment: I don't understand your line of reasoning. How does using someone's software make you trust them? Don't you need trust to run someone's software first?

Echoing similar comments on this thread. The action in itself is mildly concerning, but the lack of foresight to see this as an issue people would want to know about, and ultimately be able to make their own decision on if they want to accept that risk or not.

"So I thought that maybe user don't want to care about this intermediate process"

Choosing to include an unverified build from a third party in a project like this introduces significant risk.

Also.. anyone know why my original comment got flagged?

Have you done this? How do you know this is true? Are there reports of trusted 3rd parties who have verified this?

So far I am 0/2 on buying IODD devices and having them fail within a couple of weeks. I gave it a good 5 years between purchases and bought a different version of the unit. Perhaps I just have extremely bad luck, but my experience is that basically anything is more perfect than an IODD.

As someone who isn’t afraid of reproducible binary blobs but would absolutely pay attention to a failure-to-reproduce report from an advocate otherwise, I’m disappointed to see you failing to do so here. If you’re afraid and not willing to prove or disprove your fears yourself, then that negates your arguments to reject binary blobs categorically, rather than conditionally as I and others in this thread are accepting. So.. of this isn’t an argument about whether this project is safely using binary blobs, it’s about propagating the belief that binary blobs are never acceptable; then while normally I would dig up proof like you seek or make it myself, proof has no bearing on beliefs and I’d best not.

I wonder how far a clanker would go if you toss if at a pile of Ventoy / "build instructions" and Nix. This is a pretty ideal place for Nix to shine.