I had no idea this issue had been identified. While I find this tool very useful, the project is seeming rather questionable to me now.
I had no idea this issue had been identified. While I find this tool very useful, the project is seeming rather questionable to me now.
I too wish the developer would respond, but I don’t think this is the catastrophe people are making it out to be. One comment seems to explain why these binaries are included:
If the hashes match the files from the Fedora or OpenSUSE releases, then does this really matter?
deleted by creator
that’s what automation is for - nobody is going to manually check them, but anyone is able to automatically set something up to check their hashes in change… the fact that it’s possible that anyone is doing that now that it’s a known issue perhaps makes it less problematic as an attack vector
That is true, but also nobody is doing it. Just like nobody is verifying Signal’s “reproducible builds”.
are you sure?
there could be thousands just waiting for a failure to come out and say “HEY THIS IS DODGY”
Yea because I tested it myself. Nobody else seems to care, and if they did, I would think there would be a public way to see regular test results regardless.
I know this exists for some projects, but somehow nothing privacy-sensitive
Is that any different from no one checking the code every update?
deleted by creator
That’s ok if we are talking about malware publicly shown in the published source code… but there’s also the possibility of a private source-code patch with malware that it’s secretly being applied when building the binaries for distribution. Having clean source code in the repo is not a guarantee that the source code is the same that was used to produce the binaries.
This is why it’s important for builds to be reproducible, any third party should be able to build their own binary from clean source code and be able to obtain the exact same binary with the same hash. If the hashes match, then you have a proof of the binary being clean. You have this same problem with every single binary distribution, even the ones that don’t include pre-compiled binaries in their repo.
The problem is not near enough projects support reproducible builds, and many that do aren’t being regularly verified, at least publicly.
Yes, that’s why im saying that this kind of problem isn’t something particular about this project.
In fact I’m not sure if it’s the case that the builds aren’t reproducible/verifiable for these binaries in ventoy. And if they aren’t, then I think it’s in the upstream projects where it should be fixed.
Of course ventoy should try to provide traceability for the specific versions they are using, but in principle I don’t think it should be a problem to rely on those binaries if they are verifiable… just the same way as we rely on binaries for many dynamic libraries in a lot of distributions. After all, Ventoy is closer to being an OS/distribution than a particular program.
On the contrary: that just goes to show what a fucking catastrophe for software freedom “Secure[sic] Boot” is.
While this is true, it only requires the shim and grub to be copied for another distro.
From other comments there are a lot more blobs than just these two.
It sounds like most, if not all, come from upstream projects.
Would be nice if the dev can respond and confirm that…
I think they did say that in the older thread. But for proper security, you shouldn’t have to trust them. You should have build tools that will re-fetch everything to create an identical build. That gives a clear chain of custody, which proves that morning has been tampered with.
It sounds to me as a documentation issue, as the next comment says, simply including a
wgetscript should solve this.