Ventoy - 718 Shades of Open Source
Introduction
Ventoy is a great tool for teaching your flash drive how to multiboot, developed by Hailong Sun aka longpanda. Just install it on your flash drive, download any popular Linux or even Windows image (.iso, .wim, .img, .vhd(x), or .efi are supported) and voila - the image is ready to play with after rebooting. The application is licensed under GPLv3 - free and one of the best software licenses on the planet.
Many people are still using it happily without concern, but there are some alarming threads on Ventoy's Github page:
When the project started - the first months or maybe even a year there was no guide or any instructions on how to build Ventoy from source. One and only option: download from Github or official website. Should say the official website is heavily promoted: the Github page, source code and more - the application interface: there are 30 "ventoy.net" links on Github like Install & Update https://www.ventoy.net/en/doc_start.html
!
Seems like the author is madly in need of self-promotion. OK, this is probably the least of the problems here.
Then the documentation was finally made available: BuildVentoyFromSource.txt. Athor said that his build environment is based on Centos 7.9, which is currently EOL - "End Of Support" date is June 30, 2024. This fact definitely doesn't make Ventoy any more secure.
Do not change the radio station, hardcore is coming. The build documentation page is pretty big - 257 lines, is there any automation like GNU Make, CMake, Meson? No, nothing like that, just this:
3. All in one script
==========================================
I have made an all-in-one script `all_in_one.sh`. You can run this script to build and pack ventoy.
Great, where's the script? Github search is helpful this time: INSTALL/all_in_one.sh. That script contains 18 more Bash scripts! Kind of overkill for a build system.
How about the dependencies? Some of them are done right - link to source code, version, script or command set with build options:
But not all modules have a build.sh script or some notes. BOOTX64.EFI is from openSUSE:
What is vtoytool_64? No build notes and no any reliable information in the "update for new release" commit message.
In general, it's not common in open source to include the archives, kernel modules, EFI bootloaders and other binary files in the source code - Git LFS was invented to handle it all. But Ventoy doesn't seem to care about any of the major software development patterns.
- Xz archives in the source code:
$ find . -type f -print0 | xargs -0 file | grep -v "ASCII" | grep "executable"
INSTALL/ventoy/common_bootmgr.xz
INSTALL/ventoy/dragonfly.mfs.xz
INSTALL/ventoy/wimboot.i386.efi.xz
...
- EFI loaders:
$ find INSTALL/ -name *.efi | wc -l
18
- Binary blobs:
$ find . -type f -print0 | xargs -0 file | grep -v "ASCII" | grep "executable" | grep -v "script" | wc -l
153
- Build instructions - only 15:
$ find . -name build.sh | wc -l
15
- GRUB modules:
$ find . -name *.mod | wc -l
859
- All ELFs files:
$ find . -type f -exec file {} + | grep ELF| wc -l
718
How to maintain this open source project if the author forgot the blob info? Just try to replace it with another one from Censos, openSUSE or Fedora? What about security issues in these blobs, many of them were updated many years ago? So many rhetorical questions here, and one thing is for sure: part of this project isn't open source because of these blobs.
Vacation
Dear community,
I hope this message finds you well. I want to take a moment to address the concerns raised in Issue #2795 regarding the BLOB functionality in our app. First and foremost, I sincerely apologize for any confusion or frustration this may have caused. I was on vacation during this time, and I understand that my absence may have contributed to the lack of clarity surrounding this issue.
The BLOB feature is an important aspect of our app...
As I return to work, I will prioritize updating the documentation...
...
Post source
Then the author decided to take some time off, and many Github users are sure that this was not a coincidence. After a few months he returned, but he was still too busy to leave any comment related to blobs. Some people tried to help and published their blob research, but it was all ignored.
So what? Linux kernel has blobs too
The blobs in the Linux kernel have been discussed many times. They were mostly used for hardware with closed source firmware like network or video cards. And of course, there aren't any GRUB blobs or other unknown modules in the kernel source code.
Are these blobs useful for possible OS hacks or user data leaks?
In short - yes. Ventoy uses WinInjection and LiveInjection to inject files into images. Ventoy has access to image and system SSD or hard drives, so it can theoretically inject some malicious code that can even survive a system reboot.
XZ-utils hack story in a nutshell for skeptics
Backdoor in upstream xz/liblzma was discovered in 2024. A new contributor sent in patches that added complex macros to the main build system, the code was poorly readable, and then the backdoor was included. Is the situation with Ventoy similar to XZ? No, it's different and entirely up to the project developer. Next, his blob may contain a backdoor or rootkit and he may not know it because antivirus software is not always effective against new malicious code - that's why open source software is important: you know what code you're running.
Final note
This is hardly open source, with many developer patterns broken, the maintainability of the project is not great. Some blobs are unknown and you should trust the developer that they are not malicious. Ah, there's also no normal build system, the author prefers 10+ bash scripts instead. Many people will argue that this project is very complex and there's no way to do it better, but there are good examples of large projects with many dependencies:
- Flathub
- NixOS
The first project was made with corporate support, the second without, and I think it's safe to say that they are doing well with their tasks - blobs, efi modules, xz archives and more.
If you're ready to jump into real open source alternative train, there are some options:
Open Source is great straight to the moment you start mixing it with other software licensing and distribution.