Update: About the BLOBs in Ventoy · Issue #3224
About the BLOBs in Ventoy · Issue #3224 · ventoy/Ventoy
In #2795 there are some discuss about the BLOBs in Ventoy. For a long time, I devoted my limited spare time to adding new features and fixing bugs and didn't get around to considering this. It shou...GitHub
filister
Unknown parent • • •My problem is that a lot of people are giving a lot of shit to open source developers, who are creating great software in their free time.
Instead of enjoying their free time, they give a lot of it to the community, and then they get accused of wrong doings if the quality of their code isn't at enterprise level. The problem is that people are being toxic to them and this makes them less likely to continue doing that. I am trying to give credit as I know how hard it is to build and support some software and I want the open source community to thrive and not turn into a toxic cesspool.
Jia Tan was a big warning for everyone, I admit, but if you look at the big picture he was a single person in a sea of open source projects and honestly speaking if we are talking of state sponsored attacks, I would say that big corporations like Cisco, Fortinet, etc. would be more of a target than small open source projects. I just wish we could give the guy some credit for all his work and at least let him prove that those blobs are harmless.
I also think a big part of your qualms is the fact that he is Chinese and you are less likely to trust because of your bias.
filister
Unknown parent • • •The guy is trying to address the issue and he is building this in his free time. Give him some credit at least, I am sure this is consuming a lot of his free time.
I personally find this Ventoy an amazing piece of software and he also seems to be willing to address the issue and be more transparent in the future which is also commendable.
Ferk
Unknown parent • • •To me, what matters is what guarantees they offer and/or plan to offer, not some subjective and fleeting idea of people online having expectation of at what speed things need to be done.
Can someone do it faster? then do it (and do it in the open, so anyway Ventoy can benefit too so essentially you'll be contributing!).. but if you jump and start using a fork that has not done already the work that is currently being done, then you are placing your trust in a much much worse and shaky ground. I definitely would trust LESS a newcomer, it'd be so easy to fork, promise the same as it's being promised without actually doing the work and then inject malicious code into it. They would have very little to lose.
Vincent
Unknown parent • • •Zenlix
in reply to Der_Fossyler • • •Is there a good alternative to ventoy?
Of course I coukd flash the iso directly to the usb stick but thats not what I mean. I mean a trustworthy foss ventoy alternative.
bricked
in reply to Zenlix • • •GitHub - thias/glim: GRUB Live ISO Multiboot
GitHubEngywook
Unknown parent • • •Accept it or not, you choice. Nobody cares.
Is frankly annoying to see how much shit FOSS (or OSS) developer have to eat for every little misstep or for not employing their unpaid time to solve other people's issues (some of which are really laughable, btw).
Autonomous User
in reply to Engywook • • •A blatant lie, we see 600+ who do care on the linked page. github.com/ventoy/Ventoy/issues/2795
Who lets malware infect them because it's unpaid?
Ferk
Unknown parent • • •Any "action" that does not result in guarantees isn't helpful to solve this. So again, what I care about is guarantees.
For example, one way to "guarantee" that there's no code that's unaccounted for would be to achieve reproducible builds that can be rebuilt and obtain always the same binary bit-by-bit. So if the binary blob resulting from compiling from clean source matches the one offered then that's proof that the distributed binary was built cleanly and there was no malware being slipped through.
The issue is that this wouldn't just be a Ventoy problem, but also an upstream problem, since all projects Ventoy depends on would need to be, themselves, reproducible. So this wouldn't be an easy task, or even a task that Ventoy should do on their own, imho.
I definitely wouldn't trust that either until there's guarantees. Again, I only care about what guarantees are offered. It's not about who is the one managing the github account and/or what subjective reputation that random anonymous person might have.
The problem isn't the existence of precompiled binary blobs either, so removing the binaries is not solving the issue. The problem is in the traceability and what guarantees we have that the final collection of compiled binary blobs that ultimately is offered for download (and we do need binary blobs for download ultimately) is actually corresponding to libre/open source releases without potentially malicious code.
I don't think the maintainer went away. I've seen successfully maintained projects with much slower pace than this, specially projects for which stability is important. Last Bash commit was in 2024 and I wouldn't say it's unmaintained. Ventoy had a release 3 months ago.
Also, would it be bad if that was what triggered the interest to work on it? I mean, the post straight away mentions the github issue where that fork was advertised, and it implies that it's in that issue where they noticed that people have started to care about the blobs. So it could well be that they saw there's people who care enough to spend their time working for it (ie. they even made a fork), so why not open the doors for them? It does not have to always be drama.
GitHub - fnr1r/ventoy-cpio: An alternate ramdisk for Ventoy
GitHub