mirror of
https://github.com/ventoy/Ventoy.git
synced 2026-03-03 00:07:49 -05:00
[issue]: Remove BLOBs from the source tree #2162
Labels
No labels
Denied Feature Request
File Corrupted
Fixed
Good practice
Not an issue
Not planed
USB 2.0/3.0
USB Hardware Issue
Wait Upstream Fix
bug
documentation
duplicate
enhancement
help wanted
question
wontfix
【Tested Image Report】
【Tested Image Report】
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Ventoy-ventoy#2162
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @FairyTail2000 on GitHub (Apr 3, 2024).
What happened?
Due to the recent XZ-Utils drama I checked the code and I'm appalled. There are more BLOBS than source code.
github.com/ventoy/Ventoy@3f65f0ef03/cryptsetupgithub.com/ventoy/Ventoy@3f65f0ef03/Unix/ventoy_unixgithub.com/ventoy/Ventoy@3f65f0ef03/DMSETUPThere is no reason to have those not be build in the release process. Of course it's convenient, they are prebuild, it's fast and nobody has a problem with it.
Recent events however showed that these BLOBs can contain everything and nothing. The build instructions would not produce the exact same executable for everyone. It's better to have GitHub build it on-push and use them out of the build cache.
I would do it myself, but unfortunately I'm not familiar enough with the Ventoy build process to actually do it. I understand that removing BLOBs isn't a priority over new and shiny features. But due to recent events, this should be rethought.
Thank you for reading this and I hope for a productive conversation
@REALERvolker1 commented on GitHub (Apr 3, 2024):
Hear hear!
@FairyTail2000 commented on GitHub (Apr 3, 2024):
For those that are not familiar with the xz-utils backdoor, here is the original email send by Andres Freund who discovered the backdoor:
https://www.openwall.com/lists/oss-security/2024/03/29/4
@elypter2 commented on GitHub (Apr 3, 2024):
Ventoy is in a quite unique position to be the target of state and non-state adversaries as malware and exploits could not only target certain installations or distros but the whole user base. In the face of headlines about linux desktop percentages ventoy could attract focus in search for new vectors.
@jeekkd commented on GitHub (Apr 3, 2024):
I fully agree, I use this not just at home but work too!
@exalented commented on GitHub (Apr 7, 2024):
Don't get your hopes up this has been an issue for a very long time. Use something else!
https://github.com/ventoy/Ventoy/issues/132
@digitalspaceport commented on GitHub (Apr 7, 2024):
Regardless of recent events, this should be addressed. Ventoy is an excellent concept and pretty solid execution, but security should be a critical focus. If the developer does or does not want to address this, hopefully some community members can contribute to alleviate this as a concern. For now I think it is a good idea to not use Ventoy myself.
@catherinedoyel commented on GitHub (Apr 8, 2024):
An XZ style attack is a once every few years worst case.
You can do harmless things with blobs and harmful things with source.
Do you want Jia Tan to come in and save us from these blobs?
The main maintainer has been on vacation for a while has only just gotten back online a few days ago.
Regarding the specifically attached binaries.
Nearby in these folders (that were last modified years ago) they show how they were built in plain text.
The build process already takes 15 to 20 minutes.
There are certainly security considerations when using Ventoy. #135
But becoming Richard Stallman and demanding no binaries at any cost is not very useful.
@OboTheHobo commented on GitHub (Apr 27, 2024):
You're missing the point. No there's nothing inheritly more dangerous about the blobs themselves. The issue is that one can't verify if it's safe or not. Source code can be audited, vulnerabilities discovered. You can't really do that with binary blobs. That's a major part of the open-source ethos.
@escape0707 commented on GitHub (Apr 30, 2024):
It's been a month. I think the developer should have enough time to respond to both the xz attack and this issue. I really hope to hear some official response.
从 XZ 的攻击到现在已经过了一个月了，我想开发者应该有足够的时间就这个 issue 所谈及的问题做出回应了。我真诚希望能够看到开发者官方的回应。
Thanks for developing this useful software.
感谢你开发这个软件的时间精力。
@bernardgut commented on GitHub (Jun 7, 2024):
SO how is this coming ?
@simon1tan commented on GitHub (Jun 15, 2024):
I found Jia Tan ^^
@sneurlax commented on GitHub (Jun 15, 2024):
I would like to volunteer to help. I guess I should get to a-forking, eh?
What's a good place to start?
@code959437957 commented on GitHub (Jun 16, 2024):
@no-usernames-left commented on GitHub (Jun 16, 2024):
Does following the documented process result in blobs which are byte-for-byte identical?
If not, then the directions serve no purpose.
@escape0707 commented on GitHub (Jun 16, 2024):
You didn't understand it. OP literally said they would like to "do it myself". It's just the developer has a better understanding of their own project and it's better for them to explain the reason why these blobs exist first so that others can contribute. It's not that the community is blaming the developer for not developing a perfect program. It's because the community wants an explanation, and the fact that it never comes after months is frustrating.
@catherinedoyel commented on GitHub (Jun 16, 2024):
The three files explicitly mentioned on the original message opening the thread.
They have either direct source code / notes referencing where the source code came from in the same folder.
Cryptsetup: https://github.com/ventoy/Ventoy/tree/v1.0.99/cryptsetup
BSD: https://github.com/ventoy/Ventoy/tree/v1.0.99/Unix
Dmsetup: https://github.com/ventoy/Ventoy/tree/v1.0.99/DMSETUP
Until you can point out a binary that has no source/readme next to it there isn't a point in yapping in this thread any more about blobs.
Regarding
I agree, and incentivized funding as been tried. It seemed like very few took up the offer of the "Ventoy Subcription". So it was removed.
https://web.archive.org/web/20230930033229/https://www.ventoy.net/en/doc_subscription.html
github.com/ventoy/Ventoy@2be340d2e8Now all that remains is generic donation pages.
Looking at the publicly viewable Bitcoin donations in total 0.0273 BTC had been received over 3 years. At the current price that equates to $600 a year. (Which has never been spent.)
I would have to guess similar amounts have been donated through PayPal, Liberapay, & WeChat.
This isn't enough income to quit job and focus on Ventoy development.
The way most of these post are written it sounds like you are accusing Longpanda is like Jia Tan.
If anything they are closer to Lasse Collin.
@KucharczykL commented on GitHub (Jul 17, 2024):
If you look at the linked https://github.com/ventoy/Ventoy/issues/132 and rerun the same commands (with added "grep -v script" to remove executable scripts which are not binary blobs) you get this:
Compare that to this:
Not only has the number of binary blobs grown from 39 to 153 but there aren't build instructions for even the original 39 blobs, not to mention today's 153.
But even if there was a
build.txtfor each blob, I daresay nobody is going to manually check 153 individual files once, not to mention regularly and automatically.@bernardgut commented on GitHub (Jul 20, 2024):
Yeah this is extremely suspicious. I will recommend any IT companies that I work with to avoid Ventoy until this is cleared. There is a reason why RMS was demanding no binaries at any cost 20 years ago and we have seen why with XZ attack. Given the current climate "Just Send me More Money And Trust Me Bro" is not an acceptable answer to the person who raised this very valid issue.
Good luck with your project.
@xcpn commented on GitHub (Aug 4, 2024):
Looks like I'm moving back to Etcher, even for home use.
It's been a long time since this came up, and devs are absent.
@TechnologyClassroom commented on GitHub (Aug 4, 2024):
I have been following this issue for some time. There is a lot of negativity here in the comments, but not a lot of people volunteering to work on this issue. Passive aggressive comments on GitHub issues are not helpful, do not help to get what you want, and make you look bad in the process. File the pull request you want to see in the world.
@KucharczykL commented on GitHub (Aug 5, 2024):
How are we supposed to file pull requests to replace closed source blobs when we don't even know how are they built?
@TechnologyClassroom commented on GitHub (Aug 5, 2024):
Try building one and see if the new binary works as a replacement. If it does, you just updated a dependency. A pull request for building one dependency would be helpful. A list can be found in this above comment and many of those are easy to find.
If the source of one binary cannot be found, create a new issue with a more narrow scope to figure out that piece.
@KucharczykL commented on GitHub (Aug 5, 2024):
I think you're failing to understand the scope and nature of the problem, and you're mistakenly putting the onus of providing the necessary information on volunteers whereas it should the author.
Not to mention some of the binaries are things like kernel builds. Good luck trying to guess which options did the author enable.
@catherinedoyel commented on GitHub (Aug 5, 2024):
In your other post you only searched for build.txt, Some of theme have .sh files nearby as well.
I was going to list them all a few weeks ago but didn't have the time.
Would you like to give it a try? I work more than full time in computer repair, I know a bit of scripting but C & build systems go over my head.
You are not understanding what I meant by that, they attempted to fund raise, very few took them up on the offer. Therefore the maintainer was not incentivized to put huge amounts of time and effort into the project. They attempted to make it more than a hobbyist project.
Since I have been mostly only working on UEFI computers where I work I don't use Ventoy as much as I used to. I have been using the generous partition count provided by GPT partitioning to have, memory test, live Linux images, WinPE, & Windows installers all on the same flash drive.
The way I do that is that I'd have majority of the drive for the NTFS partition for Windows installer & any programs or drivers I may need to install. Then unallocate 8GB from the end, put on UEFI:NTFS from Rufus onto a 16MB partition since some motherboards do not have or have broken NTFS drivers, use another 16MB for memory test, put on Linux Mint on a 4GB partition, Win10 PE on 3GB partition. This would be a real alternative to saying "I'm just going to use Etcher" since the main draw of Ventoy has always been multiple environments on the same drive.
@TechnologyClassroom commented on GitHub (Aug 5, 2024):
I understand the issue and that is why I was watching the issue for developments. The issue matters. What I found in my inbox was an anti-pattern of people who also think the issue is important passive aggressively demanding free labor without contributing. That behavior is toxic and unhelpful. Help if you want to help. Ask questions if you get stuck. Donate if you can't help with your time.
Edit: Saying you'll donate only if someone does what you want is toxic too. When this issue is closed, there is not a check on whether you followed through. Donate or not, but don't be a jerk to people doing good things on the Internet. I donated $25 today. Here is a link to ways to donate.
@Long0x0 commented on GitHub (Aug 5, 2024):
I took a quick look at the repo and found most (142/153) of the blobs were built by scripts or documented:
and these ones were not (11/153):
@Thrilleratplay commented on GitHub (Aug 5, 2024):
You are not understanding. You are demanding the author fix a problem you have while giving nothing but hostility. Step back and think how could you help. This is an issue that took time to create and will take time to remediate.
As for build flags, does it matter? If you can come close to recreating them, it would take far less time for the author to hand them over than listen to people whine about how they gave the world Ventoy but it isn't enough. If you do not like it, go else where. Fork the project to remove the binary fines. Shut up or standup and help.
@KucharczykL commented on GitHub (Aug 5, 2024):
I am just a user of Ventoy who agrees that the binary blobs are making the project look less trustworthy. The author can take that criticism as they see fit. I don't demand anyone does anything so you're shouting at imaginary people.
@Thrilleratplay commented on GitHub (Aug 5, 2024):
@Long0x0 How did you decide what was built a script or not? Of the list
and these ones were not (11/153):IMG/mkcpio.sh
IMG/cpio_arm64/ventoy/busybox/a64IMG/cpio_mips64/ventoy/busybox/m64VtoyTool/build.sh
VtoyTool/vtoytool/01/vtoytool_64VtoyTool/vtoytool/02/vtoytool_64The DragonFlyBSD repo seems to provide the source for two more:
Unix/ventoy_unix/DragonFly/sbin/dmsetup- here( maybe)Unix/ventoy_unix/DragonFly/sbin/init- hereThe remaining are UEFI bootloaders that may come from GRUB but I have not verified this
INSTALL/EFI/BOOT/grub.efiINSTALL/EFI/BOOT/grubia32.efiINSTALL/EFI/BOOT/mmia32.efiLiveCD/GRUB/bootx64.efiLiveCDGUI/GRUB/bootx64.efi@nroach44 commented on GitHub (Aug 5, 2024):
At the very least GRUB (in
LiveCDGUI/GRUB/bootx64.efi, which definitely appears to be at least partially sourceless) is GPL3.github.com/rhboot/grub2@6cac608cbe/COPYING (L34)There is no onus on other people or the upstream developers to provide sources for someone else's distribution.
The perceived hostility is likely a result of being ignored. This exact situation plays out time and time again when GPL requests / reminders are ignored.
If they actually engaged in good faith, we could work towards a resolution.
@Foxboron commented on GitHub (Aug 6, 2024):
It's fairly trivial to confirm this.
Because ventoy supports shim, and by extension secure boot, these files needs to come from a signed Linux distro. In this case they are taken from Fedora releases, and OpenSUSE apparently, as they publish shim binaries and grub binaries signed by their certificate.
For instance,
INSTALL/BOOT/BOOTX64.EFIis taken from OpenSUSE.The
LiveCDbinaries are just small grub binaries with an embedded config to load an grub.cfg. This is validated by just runningstringsand see the embbed config.Which means they are just trying to load the given
grub.cfgfound in a parent directory.It would probably be good to document the origin of the binaries, but you can't remove the bootloader binaries without ruining the Secure Boot support Ventoy relies on as they probably won't get their own bootloaders signed.
@antiufo commented on GitHub (Aug 6, 2024):
Even just adding a bash script that
wgets the prebuilt binaries from reasonably trusted sources (Debian, Microsoft...) would do a lot to improve confidence in this project.@nehemiagurl commented on GitHub (Aug 6, 2024):
@ventoy I know FOSS maintenance is hard and thankless work without much funding. and I'm sure this thread has caused you a big headache.
I love ventoy and I wouldn't want you to burn out. I'd love to give money to support this project.
but I have to first know I can trust you.
I promise that as soon as this gets satisfyingly fixed and the worries come down, I'm becoming a regular financial contributor. and I'm sure many in the thread will dot the same.
but please. you have to demonstrate we can trust this project.
@sneurlax commented on GitHub (Aug 6, 2024):
but software takes work, therefore it's not
it's
as other commenters have pointed out, the author provided a way to fund this project and it failed to be funded, so these promises are empty.
if you're here complaining, make a PR instead
@nehemiagurl commented on GitHub (Aug 6, 2024):
not a developer, I don't know how to code. I offered what I can give, which is my money, but glad to know that for you the only assistance that counts for you is the one I can't give. I think the maintainer will be glad to know that despite your advice that I give nothing, I will continue with my plan to contribute cash once I can be relatively assured I'm not giving money to Jia Tan.
@TomaszGasior commented on GitHub (Aug 6, 2024):
Stop that discussion. People here are subscribed to get to know about what is happening to fix the issue. Your personal opinions about money and making PRs and FOSS contributions — all of it doesn't matter.
If your don't have anything useful for fixing the issue to add here — don't write comments. Thank you.
@Long0x0 commented on GitHub (Aug 6, 2024):
@Thrilleratplay
It seems that
IMG/mkcpio.shdoes not generatea64andm64directly. But they are the same files asINSTALL/tool/aarch64/ashandINSTALL/tool/mips64el/ashby comparing the hashes, and come from busybox.And
VtoyTool/build.shonly generatesVtoyTool/vtoytool/00/**.@Toolybird commented on GitHub (Aug 6, 2024):
Hi folks, I am the author and maintainer of the Arch Linux AUR PKGBUILD which attempts to build most of Ventoy from source. This means I am very well placed to know about the origin of every single file in the package. Inside the PKGBUILD I have documented everything I can to the best of my ability.
Honestly, the amount of FUD (and even racism!) in this thread is really quite disgraceful.
It's true that the build system is a mess. It's basically a bunch of shell scripts all strung together. It's like @ventoy has never heard of a Makefile :)
Anyway, my take on the whole situation is that the Ventoy author is an honourable person. Of course, I cannot be 100% certain, but I firmly believe there are no backdoors or anything dodgy going on here. Everyone needs to chill out a bit.
I'd be willing to help @ventoy try and get a proper build system going. I have proved that we don't need to rely on Centos 7 as a build environment.
@sneurlax commented on GitHub (Aug 6, 2024):
Feel free to tag me if there are any tasks which would be well-suited to an experienced coder that's nonetheless new to this codebase. Active Ventoy user and programmer looking to contribute back 👋
@onnyyonn commented on GitHub (Aug 7, 2024):
@Toolybird AUR user here. Thank you for maintaining it. I skimmed through your PKGBUILD, and made a list of binaries that are not built from source. Please correct me if I made any mistakes or omitted something.
The following binaries are downloaded from 3rd party:
The following binaries are taken from Ventoy repo. Some of them can potentially be downloaded from 3rd party directly. But sources are not known for a few others:
Would you say this is correct?
@purpleidea commented on GitHub (Aug 7, 2024):
It's a bit of a shameless plug, but I've built an alternative and fully transparent way to provision machines. More distro support patches are needed though, but it's awesome to use. Details here: https://purpleidea.com/blog/2024/03/27/a-new-provisioning-tool/ It's part of the https://github.com/purpleidea/mgmt/ project.
@robertkirkman commented on GitHub (Aug 8, 2024):
useful idea however it appears that your project has a hard dependency on the device having PXE-over-ethernet boot support which is not guaranteed and is not the target use case for Ventoy.
@haha-689 commented on GitHub (Aug 8, 2024):
It's still a cool and useful tool, don't take the dislikes personally.
@purpleidea commented on GitHub (Aug 8, 2024):
You can use an IPXE or netboot.xyz USB stick to kick it off for any machine that doesn't have built-in PXE/netboot support.
@digitalspaceport commented on GitHub (Aug 8, 2024):
Thanks for derailing the topic @purpleidea. It is really not helpful to the issue at hand with Ventoy. This is a poor choice of timing to get into marketing. Before you respond to this, maybe don't and instead consider deleting your posts. Just a suggestion.
Thanks for the generous offers of time and skill to help bring Ventoy builds to a verifiable rebuildable state @Toolybird, as an AUR user also I find @onnyyonn findings very interesting. Also thanks to all the many others who are commenting on the issue at hand and offering time and skills to rectify the issue and get Ventoy back to being a tool we can all trust implicitly.
@ghost commented on GitHub (Aug 16, 2024):
I got windows w/ ventoy and it was very slow for me, then I switched with linux still using ventoy and it was faster, did the malware make my windows install w ventoy bad to force me to use linux?
@Lucy-dot-dot commented on GitHub (Aug 16, 2024):
@RishiSlop this issue does not mean that ventoy contains a virus. It also doesn't mean that it doesn't it means, we don't know and we can't really check for ourself full at the moment. If Windows feels slow that's probably a driver issue. Also we don't know if you used an official Windows image or slimmed down (tiny11 or similiar) which can have issues. Your issue is unlikely to be caused directly by ventoy or the unchecked binaries in the repo. If you believe Ventoy is the cause, burn the image with rufus and try again
EDIT: Fixed typo
@grepwood commented on GitHub (Aug 16, 2024):
Windows is the malware.
@Joseph-DiGiovanni commented on GitHub (Sep 2, 2024):
Can someone outline what exactly needs to be done to eliminate these blobs? My understanding is while there are many precompiled binaries only a few exist with zero source or even so much as brief explanation of their origin/build process.
If that understanding is correct after this much time the project should absolutely be treated as malware until someone can at least be bothered to officially explain the origin of these binaries.
@grepwood commented on GitHub (Sep 3, 2024):
On Linux, use the versions of those blobs that are provided by the distribution's package manager.
On Windows, let them eat cake.
@Joseph-DiGiovanni commented on GitHub (Sep 3, 2024):
If every binary has a known origin this is a fine solution, but I believe there are still some that just don't have one.
Remaining silent on a huge accusation like your project being the next XZ Utils is nothing more than a stall tactic in my eyes.
@bernardgut commented on GitHub (Sep 3, 2024):
Since the maintainer doesn't want to do basic open source project management/create tasks tickets so people can contribute and help him. Let me try to spell it out for him:
Something along those lines. Did I miss something ?
PS: @ the maintainer : man you are really making it HARD to want to help you. NOBODY will ever spend a week creating a PR for it to be discarded because it doesn't meet whatever criteria you have in your head. Maybe if you spend 10 min SPELLING OUT what you want to be done for fixing this issue instead of begging for money, this thread would have been closed last year... Plenty of people know how to fix this issue. Nobody is going to waste their time trying to figure out which solution you deem as acceptable for a PR. Just my 2 cents.
@grepwood commented on GitHub (Sep 3, 2024):
Using the following command:
I have found this list of files:
We can immediately spot that there's 3 sets of GRUB present:
INSTALL/grub/i386-efiINSTALL/grub/i386-pcINSTALL/grub/x86_64-efiFurther snooping shows that there's in fact, more:
INSTALL/grub/arm64-efiINSTALL/grub/mips64el-efiThey just escaped this rudimentary method of identification, because they are compressed:
So the first thing in our bill of materials is GRUB, for i386-pc, i386-efi, x86_64-efi, arm64-efi, and mips64el-efi.
Next we have all kinds of crap in:
IMG/cpio_x86/ventoy/toolIMG/cpio_x86/ventoy/busyboxIMG/cpio_arm64/ventoy/toolIMG/cpio_arm64/ventoy/busyboxIMG/cpio_mips64/ventoy/toolIMG/cpio_mips64/ventoy/busyboxFirst thing I noticed when browsing these directories is a kernel module:
I'm not entirely sure why is a kernel module needed... here's the source for it:
github.com/ventoy/Ventoy@c16e76130b/DMPATCH/dmpatch.cThe use case is described here:
github.com/ventoy/Ventoy@c16e76130b/DMPATCH/readme.txt (L33)I'm really unconvinced that this is needed.
Moving on, let's see what tools are exactly located in the
IMGdirectory:which brings us to:
Some of those commands I recognize:
github.com/ventoy/Ventoy@1f49265f29/BUSYBOX/chmod/vtchmod.c(seems pretty silly, but benign)I'm completely lost wtf is
a64andm64. Whoever made them, didn't bother putting any license info, program name, or disclaimer in the strings.I'm tired. This is an incredible case, but one that I'm not taking a vacation from life over.
@mpeter50 commented on GitHub (Sep 26, 2024):
Based on a comment above,
a64andm64seem to be ARM64 and MIPS64 versions of the ash shell.Or busybox as running linux
stringson it shows among others these:BusyBox v1.32.0 (2021-03-04 12:59:59 CST)built-in shell (ash)@mpeter50 commented on GitHub (Sep 26, 2024):
Also, to make it easier for anyone to see which files are the same ones, Czkawka is quite useful.
I have attached a text file with duplicates in the repo directory, so that you dont need to use it:
results_duplicates.txt
@http403 commented on GitHub (Oct 13, 2024):
A person seems to be the author replies, but in the wrong place. I can't confirm is he really the author.
https://lemmings.world/post/15186261
@grepwood commented on GitHub (Oct 13, 2024):
This is the first time I see this address. Not a good place to write something that should be read by many people.
@robertkirkman commented on GitHub (Oct 13, 2024):
a couple of points:
@KucharczykL commented on GitHub (Oct 13, 2024):
His post does not address anything at all (and it looks to be written by AI).
@grepwood commented on GitHub (Oct 13, 2024):
I appreciate, it's no small feat to build such a thing. But I'll stay away because I generally don't like social platforms. It's a huge time sink.
@mpeter50 commented on GitHub (Oct 13, 2024):
There is a new response from someone who claims to be the real developer's friend:
Source: https://lemmings.world/comment/11306760
I don't know if what they tell is true, but there are a few things to consider:
@nehemiagurl commented on GitHub (Oct 13, 2024):
I'd consider both those accounts to be untrustworthy for now. I think the safe assumption is we're still in the dark when it comes to an answer.
if somehow either of these accounts prove the truth of their identity, that would be welcome. but until that happens, let's assume they're both pretenders.
@grepwood commented on GitHub (Oct 13, 2024):
Both of those accounts are LARPing. If @ventoy wanted to clarify anything, they'd do it in this thread, not on barely known Reddit clone.
@http403 commented on GitHub (Oct 13, 2024):
The posts/comments and the account made them are now removed by mods under probable impersonation.
https://lemmy.ml/modlog?page=1&actionType=All&userId=14359241
@sswangshu commented on GitHub (Oct 14, 2024):
Hello, I have been following the posts about longpanda and after the original post was taken down, I am heading here. Like everyone here, I am in the dark of what had happened. As I mentioned in my comment, I lost contact with longpanda for sevearl months. I am worried. I have no ideas who wrote that post, who was behind this and what happened to longpanda 🙏🙏
@grepwood commented on GitHub (Oct 14, 2024):
@ventoy was last seen on June 8th when committing
github.com/ventoy/Ventoy@cb209f9b9e. This issue was filed on April 3rd. These dates are 35 days apart. Maybe communication on such a serious issue was not high on list of priorities. Edit: there are 14 commits in that frame of time.@sswangshu commented on GitHub (Oct 14, 2024):
Thank you, the last time I talked to him was before the labour day. He told me he would travel back home for a few weeks.
@github2099 commented on GitHub (Oct 14, 2024):
@ventoy activities on the Ventoy Forum align with the release schedules
Even though @ventoy is absent on Github, last visit on the Forum was October 8, strange eh?
@http403 commented on GitHub (Oct 14, 2024):
It would be best not to discuss @ventoy whereabout here, as this should be focused on the issue itself. Such topics is better suited in the forum, or Discussion tab.
@Casered commented on GitHub (Nov 16, 2024):
There's been some new @ventoy GitHub activity today, so hopefully he can answer soon! 😊
@sswangshu commented on GitHub (Nov 17, 2024):
@Casered glad to hear!
@xcpn commented on GitHub (Nov 20, 2024):
Every once in a while I remember about this Issue thread and pass by to see if the developer answered any concerns.
And every single time I get more anxious reading new replies and no answers!
@TechnologyClassroom commented on GitHub (Nov 20, 2024):
If you find yourself spending hours actively waiting on this issue, work on this issue. There is enough information in this thread to figure it out, assemble a patch, and submit a pull request.
@grepwood commented on GitHub (Nov 20, 2024):
What's exactly the use case for Ventoy? dd'ing an installer image to a USB drive has worked perfectly fine since BIOSes could boot from USB drives.
@Joseph-DiGiovanni commented on GitHub (Nov 20, 2024):
@grepwood this is not the place to be asking unrelated questions, especially ones with such an obvious answer. There is enough useless noise in this thread.
@arisudesu commented on GitHub (Nov 20, 2024):
Enough flooding the issue with pointless "waiting" comments. You only light up notifications icon, not contribute anything.
Judging from your previous comments in the issue: are you a troll? In either case, Ventoy is a tool to select and boot ISOs from removable media filesystem, which is not the same as writing one image to a USB drive.
@grepwood commented on GitHub (Nov 20, 2024):
I contributed a lot to this issue. Can you say the same?
@Joseph-DiGiovanni commented on GitHub (Nov 20, 2024):
@grepwood you went to a seemingly random issue to ask a question which is answered in the second sentence of the project readme and you think because you've made a helpful comment in the past you shouldn't be labeled a troll?
@grepwood commented on GitHub (Nov 20, 2024):
I spent a lot of time doing that research and never asked for anything in return, and this is what I get. Well, have fun looking for vulnerabilities in Ventoy. I'm leaving this thread.
@arisudesu commented on GitHub (Nov 20, 2024):
@grepwood wow, a single useful message. Well, I did the same in my one and only comment in this issue by answering to you what Ventoy is. You, however, did not mention your past comments stating:
This is a borderline trolling. Also, if you're versed about what Ventoy consists of, why are you asking something like "What's exactly the use case for Ventoy?", you already know it or you can spend some time to figure it out. You have enough technical knowledge to judge what single binaries do, but you can't understand what Ventoy does as a whole and you're asking it after you did prior research on Ventoy contents? Weird. What did you even research?
@youk commented on GitHub (Nov 20, 2024):
Would all please shut the fuck up?
@mathmakgakpak commented on GitHub (Nov 26, 2024):
First a forum senior member has said this: https://forums.ventoy.net/showthread.php?tid=2965&pid=8695#pid8695
and later longpanda wrote this https://forums.ventoy.net/showthread.php?tid=2982&pid=8750#pid8750
@ShalokShalom commented on GitHub (Jan 7, 2025):
There is an alternative
https://github.com/thias/glim
@mian196 commented on GitHub (Feb 10, 2025):
so, does this gets resolved or nah ?
@M-Reimer commented on GitHub (Feb 10, 2025):
Honestly not getting any response here feels incredibly suspicious. I wonder why noone, with interest in this issue, has started a fork, delete ALL binaries from it and add some way to auto build them all to the build system.
@dzek69 commented on GitHub (Feb 10, 2025):
Probably because of the same exact reason you did not do that 😊
@Aera23 commented on GitHub (Feb 11, 2025):
There is already instructions for building DMSETUP
github.com/ventoy/Ventoy@3f65f0ef03/DMSETUP/build.txt@floweringnights commented on GitHub (Mar 7, 2025):
now that 1.1 is out, what next? any responses from the creator himself about the issue yet?
and before anyone replies that I should contribute or whatever: I'm not a programmer, I cannot code, and it seems people in here don't really like financial contributions after when the issue is addressed.
@Fredolx commented on GitHub (Mar 9, 2025):
If you want this changed, you should fork it. There's nothing bad in having a fork. Call it SafeVentoy or something. The community will be grateful. Whether or not Longpanda accepts a PR doesn't really matter, it would simply be his loss.
@gk-devhub commented on GitHub (Mar 11, 2025):
If you have security concerns about Ventoy or any other single- or multi-boot usb pendrive setup methods, or if you're just interested in a quick and easy multi-boot installer setup without using any 3rd-party tools, then you should check out this alternative multi-boot setup method that I just published.
Windows and Linux multi-boot USB installer setup without using Ventoy
It covers typical everyday use cases and it's VERIFIABLY CLEAN as it doesn't use any 3rd-party tools, binary blobs or modified executables. All executables are coming directly from the official Linux and Windows installer iso's. No 3rd party executables.
@dzek69 commented on GitHub (Mar 11, 2025):
@gk-devhub it's nice to have an alternative, but this is FAR from being Ventoy alternative. It's just a rather tedious way to multi boot from a single pendrive, but without support for any real advantages of Ventoy
@gk-devhub commented on GitHub (Mar 11, 2025):
@dzek69
I never said that it was. At least, not in the sense that you're implying (i.e. as some kind of equivalent or comparable replacement). I only said that it's an alternative multi-boot setup method. That's not the same thing.
Any multi-boot setup method is an alternative to any other multi-boot setup method. Some are better alternatives and some are worse.
All of them have their pros and cons and their tradeoffs and limitations. In fact, I state some of those limitations in the readme file.
So this method is not supposed to replace Ventoy or compete with it. That's NOT its purpose.
Its purpose is to address the "security concerns" angle. Which is why I posted it here on this thread.
The basic idea here is that if you wanna use Ventoy, but you're uneasy about the potential security issues as discussed by others on this thread, and your use case is simple enough, then you can use this alternative method that is verifiably clean, covers your use case and easy to setup.
Nothing more and nothing less. It's not a competitor to Ventoy and it was not intended to be.
It's just an alternative that people, depending on their security stance and use cases, might be able to use to give them peace of mind with respect to security.
That's all. Simple as that.
You can literally carry out all those steps in 10 minutes to set up the multi-boot pendrive. And "10 minutes" does NOT qualify as "tedious". Especially not in the context of a setup task in a linux environment;) Yes, it's not drag-and-drop. But it's far from being tedious.
@youk commented on GitHub (Mar 11, 2025):
You should really make up your mind about what you are selling here.
Yes it does. And it is obviously not for you to decide what other users might consider tedious. If you really care about something not tedious, think about providing a script. The positive side effect would be the absence of funny screenshots.
With modern live/immutable Linux distros I don't even spend much time on setting up the entire OS. Let alone spending time on "setup tasks". Have more productive things to do.
@fnr1r commented on GitHub (Mar 24, 2025):
Working on it. (at least for Linux)
@erikschul commented on GitHub (Mar 24, 2025):
@fnr1r I'll believe it when the PR is merged into the main branch and not present in the releases.
@fnr1r commented on GitHub (Mar 24, 2025):
@erikschul The thing is... The Ventoy's build system is so annoying that I'm also rewriting the build system.
If anyone's interested, my work is here: https://github.com/fnr1r/ventoy-cpio
@erikschul commented on GitHub (Mar 24, 2025):
@fnr1r Good idea. Maybe document your findings so it's easier to onboard other people on maintaining the project.
And focus on making it trivial to make reproducible builds so the community can identify issues early.
Ventoy is a critical tool that can unfortunately inject malware at root level, so I'm surprised that people even use it. It's a very dangerous tool in that we just can't be sure that it doesn't contain malware. It should ideally be entirely free of dependencies and have a minimal codebase that is easily reviewable.
@dzek69 commented on GitHub (Mar 24, 2025):
It could but it can be verified by doing the installation with and without Ventoy and comparing the disk contents. If Ventoy would inject malware for everyone - I'd be way too obvious and would create a backlash. If that would be random but too frequently and people would notice too.
So what's left? Targeted attacks - picking just the best targets (but how do you do that on a installation medium step? Maybe by looking at CPU, determining if it's a server CPU or "home use" CPU), and doing it at random, but not too frequently. Here you can avoid detection for some time.
While it's possible I think the risk is so low, that not much people care.
Also I bet 99,9% of the people just does not acknowledge the fact at all. They just found someone recommending a nice tool and they use it.
It's also impossible to read, understand and follow updates of all the code you want to run. I wouldn't do that myself and I would have to rely on others anyway.
@fnr1r commented on GitHub (Mar 24, 2025):
Update: I got all tools to compile, but the cpio is way too large to be a viable replacement (for now at least). Still, I invite everyone to go and try it out.
I also made a release for those who don't want to build this themselves.
Goodnight (I guess)
@fnr1r commented on GitHub (Mar 29, 2025):
Alpha 3 is out. If someone's interested in testing it, it's here. Once again, feedback is appreciated.
@eugenesan commented on GitHub (Apr 7, 2025):
There was no response from the maintainer for over a year.
For those not willing to wait and looking for an alternative, there is one, GLIM.
It's nowhere near the feature set of Ventoy but can cover 80% of use cases, especially for those friendly with Linux.
The original GLIM project was already mentioned in this thread but it was not updated for some time so I had to fork it at: https://github.com/eugenesan/glim. I based my work on another fork https://github.com/cshandley-uk/bash_glim.
Basically, I added basic Windows support and various improvements.
Feel free to play with it.
Since I am not sure if my changes will be accepted by parent forks, I recommend monitoring all 3 for time being.
@fnr1r commented on GitHub (Apr 8, 2025):
GLIM is nice. I like its less invasive approach, but it comes at the cost of not having as many features and not having a generic option. Ventoy has one, but I'm not sure if it works.
But using a less invasive approach for distros who support it is something that should be added to Ventoy, since it shouldn't interfere much with other features.
Also I'm too lazy to switch from Ventoy. I'd rather actually make it better since it has a lot of potential.
@eugenesan
@cshandley-uk commented on GitHub (Apr 8, 2025):
Thanks for mentioning my fork (which adds easy support for ISOs over 4GB), I had been wondering about mentioning it here, since I stopped using Ventoy. I'll probably take a look at your pull request this weekend. I don't intend to reply further here, as it's off-topic.
@dzek69 commented on GitHub (Apr 8, 2025):
GLIM is not an "80% alternative" to me, if it has a hardcoded list of supported OSes:
@eugenesan commented on GitHub (Apr 8, 2025):
Indeed, without Ventoy's "dirty black magic" that blindly boots almost any ISO, GLIM has to deal with each type of ISO separately. Despite that, it still works with most modern Linux/BSD/Rescue ISOs and able to boot Windows10/11 Install from a partition. In my personal book, that's 100% success ;-)
Maybe 80% score is too optimistic for most, but in cases where security is important convenience is a small price to pay.
@youk commented on GitHub (Apr 8, 2025):
This is far from truth. Ventoy breaks pretty regularly with multiple ISOs. What one sees as magic is in fact tedious maintenance. But ignorance is bliss, yeah.
@extrowerk commented on GitHub (Apr 8, 2025):
I personally use every chance to explain why is it a terribly dangerous idea to use ventoy. Everybody should consider it as a malware.
@trmdi commented on GitHub (Apr 9, 2025):
You can't make claims without evidence. That's just a wild guess. By your logic, does that mean Microsoft Windows or any binary software is malware?
@youk commented on GitHub (Apr 9, 2025):
@extrowerk Malware assumes malicious intent. Are you able to demonstrate it? If not, what you are doing is spreading FUD. Ventoy is just malware as any device with proprietary firmware (which means practically ANY device).
Am I saying that running random binaries is secure? Hell no. But it is all about risk profiles. No need for drama here.
@arvigeus commented on GitHub (Apr 9, 2025):
Take your fight somewhere else, it has nothing to do with the issue.
@youk commented on GitHub (Apr 9, 2025):
So what is the issue then? World is in the dark, please enlighten it.
@arvigeus commented on GitHub (Apr 9, 2025):
#2795
@youk commented on GitHub (Apr 9, 2025):
You have no conception of the rationale, do you?
@extrowerk commented on GitHub (Apr 9, 2025):
@trmdi I didn't say the program was malicious. I said that any sane person should consider it malicious.
@youk There are many channels on the internet promoting Ventoy as a simple, ready-made boot solution. The target user group is not capable of risk assessment, so they cannot realistically accept the potential risk, but the peer pressure is overwhelming. The project is considered malicious as long as the project does not show any intention to solve this issue.
@youk commented on GitHub (Apr 9, 2025):
What is the target group? Housewives?
How did you estimate the targets' group capability? Is it your fantasy guess?
As if it isn't so for vast majority of consumers of any digital technology.
That is only your personal opinion. Which is quite ridiculous, TBH.
There are many reasons people don't do something. Stop with your FUD already.
@extrowerk commented on GitHub (Apr 9, 2025):
@youk I agree that we don't agree. Still: caution always pays off.
@rfc-2549 commented on GitHub (Apr 9, 2025):
So they ain't going to unbackdoor this in the foreseeable future, huh?
May I recommend an alternative to Ventoy that need not an USB device: https://ipxe.org
@youk commented on GitHub (Apr 9, 2025):
Finally someone found the backdoor. Please share the details.
@rfc-2549 commented on GitHub (Apr 9, 2025):
Ah no i did not find any backdoor i just read in /g/ this is backdoored and I believe them because like Abraham Lincoln said "If it is on the internet, it is true"
@fnr1r commented on GitHub (Apr 9, 2025):
Foreseeable future - no. I am trying to, but it's not easy and it'll take time.
It'd be nice if someone else would help, but Ventoy is complex, so I won't blame anyone for not wanting to get involved.
I have some notes in Obsidian that could help possible future contributors familiarize themselves with how Ventoy works and I can publish them in something like
ventoy-meta.I will reiterate - for now I'm focusing on the recreating ramdisk, which is... done I guess, but it's still imperfect in regards to it's size on mips64el, the toolchain it uses (old Ubuntu + new Debian for i386 + whatever else Ventoy uses) and I don't have the time to test it on every distro.
Help with the last one would be great, but I won't force anyone.
Also after I finish
ventoy-cpio(or at least get it to a usable state), I'll focus on building GRUB, since it's a shared component across all compatible OSes. I already have a Makefile that kinda does this, but it's still messy.Once that's working I'll try to optimize init in the ramdisk and add the ramdisk-less boot from GLIM as an option to Ventoy.
All of this will take time, but I think it will be worth it.
So... I'm still waiting for feedback. Y'all can also add working distros to
ventoy-cpios GitHub wiki. It should be open to edits from anyone.Cheers 👋
@fnr1r commented on GitHub (Apr 9, 2025):
Also since I added
arandinotifyd, Alpha 5 is out. The x86 ramdisk is now finally smaller.I don't know why
aris needed, but it's in the official ramdisk, so...@SysAdminDoc commented on GitHub (Apr 9, 2025):
I just wanted to chime in and say put me in the screencap.
@Glass47 commented on GitHub (Apr 9, 2025):
How does this make you feel that there are over 400 people agreeing with initial post yet main dev still hasn't addressed or answered this?!
Is that also a fud? Lol
Or maybe you are an alt account from main dev trying to defend himself? You never know.
@Glass47 commented on GitHub (Apr 9, 2025):
It doesn't need to inject malware, all it needs to have is a backdoor, just like how XZ had backdoor.
Was it actively used? Maybe, was it obvious? No, did most people deem it safe? Yes.
In reality it wasn't safe because 0day was existent. Just like how you can have exploit sitting to be activated one day..
But anyways it's not going to be my loss at the end of the day when shit hits the fan..
@Glass47 commented on GitHub (Apr 9, 2025):
It's mind boggling how does it not raise any red flags to these people.
It's fine to have devil's advocate, but you can easily shut them up by asking one question - Does it not raise any red flags that developer has been active - yet he hasn't responded to address this at all? Despite this initial issue having 100's of people agreeing..
@gpz1100 commented on GitHub (Apr 9, 2025):
I have no problem using ventoy for testing purposes. Any software that goes on production devices is installed using original sources with no intermediate bootstraps (ie ventoy).
@reavpC6K commented on GitHub (Apr 9, 2025):
All garbage philosophy. You shouldn't earn a penny, kopek, whatever your unit if you actually use this in production. Dirty XZ runs on millions of OS installs before we assume Jia Tan and Hailong Sun are the same person.
@TechnologyClassroom commented on GitHub (Apr 9, 2025):
Instead of calling the developer a malicious Jia Tan who is hacking your USB with malware, use this energy to work on the issue. The information you need is in this thread.
@youk commented on GitHub (Apr 10, 2025):
I'm sorry to disappoint you, but it doesn't make me feel. Nobody owes you (or anyone else) anything. Your demands are nothing more than a child's frustration.
You are not even able to read. Get lost.
@mpeter50 commented on GitHub (Apr 10, 2025):
It is true that we are talking about volunteer work, but if people were asking me questions concerning the security of my project, and I cared for my project, I would try to clear up what is happening, whether I consider it serious, and whether I want to work on it at all. In this case however, we didnt get even an acknowledgement, or a call for help, did we?
@extrowerk commented on GitHub (Apr 10, 2025):
Even if this is obvious to you, the project's front page should clearly state the warning:
"VENTOY TAMPERS THE INSTALLATION MEDIA AND INJECTS BINARY BLOBS."
I would say that the project should contact the major news outlets and propose an article about the inner workings of Ventoy. No one knows how many manipulated installations are running around the world, most users are probably not even aware that their installation has been manipulated. This is terrible from a security POV, and users should have been clearly informed about this from day one.
@youk commented on GitHub (Apr 10, 2025):
Are you sure you have any idea what you are talking about? What installations? Ventoy modifies initramfs of bootable media. Show any sign of the tampered installations or cut your bullshit.
@rfc-2549 commented on GitHub (Apr 10, 2025):
@youk Are you getting paid by the CCP or why are you defending a software you ain't even made a commit for?
@noscript commented on GitHub (Apr 10, 2025):
Reportedly, Stuxnet was undetected for half a decade.
@extrowerk commented on GitHub (Apr 10, 2025):
Please moderate yourself, we haven't received any usable material from you on this topic yet.
Ventoy is well positioned to support a malicious infiltration attack, basically has all the tools to insert a rootkit.
I don't need to show that the functionality is actively used. The project owner should take care of warning users and ensure transparency of project management and repeatability of binaries.
This is not happening, so it is natural that people try to warn others. Why does this bother you? Why are you against transparency? What is your motivation?
@youk commented on GitHub (Apr 10, 2025):
We? Do you mean yourself? That's because your technical knowledge on the topic is zero. You don't understand what is being communicated to you.
FUD. You claimed that it tampers with the installations. That is very easy to prove. You have zero proof. You just post your bullshit. Probably, just out of your ignorance.
You are even unable to show the presence of "the functionality". Because you don't understand a thing about Linux.
My motivation is call your bullshit.
@rfc-2549 commented on GitHub (Apr 10, 2025):
动态网自由门 天安門 天安门 法輪功 李洪志 Free Tibet 六四天安門事件 The Tiananmen Square protests of 1989 天安門大屠殺 The Tiananmen Square Massacre 反右派鬥爭 The Anti-Rightist Struggle 大躍進政策 The Great Leap Forward 文化大革命 The Great Proletarian Cultural Revolution 人權 Human Rights 民運 Democratization 自由 Freedom 獨立 Independence 多黨制 Multi-party system 台灣 臺灣 Taiwan Formosa 中華民國 Republic of China 西藏 土伯特 唐古特 Tibet 達賴喇嘛 Dalai Lama 法輪功 Falun Dafa 新疆維吾爾自治區 The Xinjiang Uyghur Autonomous Region 諾貝爾和平獎 Nobel Peace Prize 劉暁波 Liu Xiaobo 民主 言論 思想 反共 反革命 抗議 運動 騷亂 暴亂 騷擾 擾亂 抗暴 平反 維權 示威游行 李洪志 法輪大法 大法弟子 強制斷種 強制堕胎 民族淨化 人體實驗 肅清 胡耀邦 趙紫陽 魏京生 王丹 還政於民 和平演變 激流中國 北京之春 大紀元時報 九評論共産黨 獨裁 專制 壓制 統一 監視 鎮壓 迫害 侵略 掠奪 破壞 拷問 屠殺 活摘器官 誘拐 買賣人口 遊進 走私 毒品 賣淫 春畫 賭博 六合彩 天安門 天安门 法輪功 李洪志 Winnie the Pooh 劉曉波动态网自由门
With that being said. Please do enlighten us on why this isn't harmful and we shouldn't care about these blobs. With code and proofs. Not words or insults. Thank you. But we need your enlightenment
@fnr1r commented on GitHub (Apr 10, 2025):
To clarify - injecting files into initramfs is a feature. I've read the important bash scripts in
ventoy.cpioand as soon as the real init calls switch_root any traces of Ventoy are gone, unless you inject files that then add themselves to the live environment. The only thing that should remain is two device mappings namedventoyand partition name.Correct me if I'm wrong.
Also, can any discussion about distrust of longpanda be moved somewhere else? This is an issue regarding binary blobs in the repo, which is bad practice, not maliciousness. The point is to get rid of blobs from the repo, not get rid of pre-built versions of Ventoy entirely.
If someone doesn't trust longpanda's build of Ventoy, don't use it and help others improve build instructions and systems.
Speculation about longpanda being the next Jia Tan is not helpful.
I'm sorry if I'm coming off as hostile, I just want to get this fixed.
@youk commented on GitHub (Apr 10, 2025):
@rfc-2549 I didn't even touch on the topic of BLOBs. Unfortunately, you are clearly not able to understand what I was arguing about. Bye.
@rfc-2549 commented on GitHub (Apr 10, 2025):
My man I wish you a very happy life and an awesome day
@fnr1r commented on GitHub (Apr 10, 2025):
This is getting so unhinged I might as well tag @BrodieRobertson (sorry)
@rfc-2549 commented on GitHub (Apr 10, 2025):
@extrowerk commented on GitHub (Apr 10, 2025):
Sorry, but I am not a huge fan of your favorite system. Please do not limit the scope, Ventoy is clearly marketed as capable to boot other systems aswell.
@Thrilleratplay commented on GitHub (Apr 10, 2025):
Can the time and energy every one is using to mostly attack one another be used to help @fnr1r to test ventoy-cpio?
@rfc-2549 commented on GitHub (Apr 10, 2025):
My dear, if energy was used into mostly good things we would not have wars and most of the problems we have in the world, groups, organizations and communities.
the human's flawed
@git70 commented on GitHub (Apr 10, 2025):
https://github.com/fnr1r/ventoy-cpio/discussions/16
@fnr1r commented on GitHub (Apr 13, 2025):
Alpha 6 is out and I'm working on building GRUB (with overlay mounts to save time).
EDIT: Done! (kinda) https://github.com/fnr1r/ventoy-grub
@fnr1r commented on GitHub (Apr 13, 2025):
Does anyone here know which efi binary in
(VTOYEFI)/BOOT/EFIis which?MokManager is obvious, but the naming is inconsistent.
BOOTAA64.EFI,BOOTMIPS.EFI,grubia32_real.efiandgrubx64_real.efimatch the size of grub, but the rest is a mystery to me. It seems like some kind of secure boot bypassing chainloader, but I couldn't find it here.EDIT: typo
@catherinedoyel commented on GitHub (Apr 13, 2025):
Use virustotal, they should be shims from upstream Linux distro. I don't remember which, but virustotal on those files will show the certificates used to make them.
@fnr1r commented on GitHub (Apr 13, 2025):
@catherinedoyel Haven't thought of that. Thanks.
The first one I looked up (
BOOTIA32.EFI) is mostly associated with Ventoy but is also calledshimia32.efi. That's probably it. Still have to check the rest, though.@fnr1r commented on GitHub (Apr 13, 2025):
Okay. I think I get it now.
BOOTX64.EFI and BOOTIA32.EFI are shims signed by higher authorities (Red Hat, OpenSuse, the forbidden company, etc.) and grub.efi, grubia32.efi are... something signed by longpanda's private key, aptly named
grub.I still don't know where to get those shims or how to build the 2nd thing (probably something in https://github.com/ventoy/Ventoy/tree/master/EDK2/edk2_mod/edk2-edk2-stable201911/MdeModulePkg/Application), but at least I have something.
@catherinedoyel commented on GitHub (Apr 13, 2025):
This is the MOK itself we have the password to it 123 as seen in the https://www.ventoy.net/en/doc_delete_key.html
I hope the key is present here if not your new fork could create a new path, this should be the key that is the enroll.cer file. If we can't access the original you can install a new one.
@Long0x0 commented on GitHub (Apr 13, 2025):
I had listed some of them earlier: https://github.com/ventoy/Ventoy/issues/2795#issuecomment-2269378561 —see if they’re any help?
@fnr1r commented on GitHub (Apr 13, 2025):
They are. Shims + MokManager are in 5.10 (you missed the 32-bit one btw,
INSTALL/EFI/BOOT/mmia32.efi), but the other two are still a mystery.Thanks.
EDIT: It could be the bundled insecure preloader, but it's not in the build docs.
EDIT 2: I checked the hash. It probably is the preloader.
EDIT 3: Yep.
github.com/ValdikSS/Super-UEFIinSecureBoot-Disk@f49380c586/efi-tools-patches/preloader.c.patch (L11)@fnr1r commented on GitHub (Apr 16, 2025):
Progress update: I got IPXE with Ventoy patches building on Debian 12 after using NO_WERROR=1 and cherry-picking
f982a712979619dbae2c6e0d741757e2ce94be11.This took me way too long.
@fnr1r commented on GitHub (Apr 17, 2025):
For anyone who wants to try out the build system for shared components, it's here:
https://github.com/fnr1r/ventoy-boot/tree/experimental
As the branch name implies, it's still experimental. I'll squash it at some point.
@fnr1r commented on GitHub (Apr 24, 2025):
Sorry for the recent lack of progress. I'm trying to work on tools for OSes I'm less familiar with (i.e. geom-ventoy for FreeBSD and whatever else is needed). I also have a bit of a code block / lack of inspiration. I'm also learning more about the inner workings of libc (and trying to split it up into smaller libraries).
It'll probably take me a couple of days to get back on track. In the meantime, I have a poll on a new name for the project in case my changes don't get accepted upstream.
https://github.com/fnr1r/ventoy-meta/discussions/1
I'm also still accepting feedback and pull requests.
Cheers and sorry for the silence. I don't wanna spam this thread.
@dzek69 commented on GitHub (Apr 24, 2025):
No worries @fnr1r , your "spam" is much more appreciated than any other comment in this thread 🙏🏻 Thanks for the good work.
@EpicLPer commented on GitHub (Apr 28, 2025):
@fnr1r Protogens taking over the world one by one, but first they take over your ISOs 👀
Great work so far!
@AchmadFathoni commented on GitHub (Apr 28, 2025):
Is the author still silent? Very fishy, no little convenient worth security risk.
@Aera23 commented on GitHub (May 2, 2025):
I wonder why wouldn't they have removed the issue to hide it?
If not... maybe they just left this as is... tho a concern to me is if the binaries are out of date and no longer secure...
an attacker would wait for the binaries to be insecure then make an exploit and distribute it somehow.
@AchmadFathoni commented on GitHub (May 2, 2025):
It will be more fishy if they remove this issue, being neutral in this scenario is the best strategy to maintain status quo
@dzek69 commented on GitHub (May 2, 2025):
But... what would be the vector of attack in this case? An ISO file with a malware? Then even without Ventoy you're out of luck. I don't see a way to exploit an existing Ventoy install unless you put a malware on the disk yourself or your already infected PC does that for you, but both ways it's not Ventoy being exploited.
I don't like random binaries, but let's get real with throwing attacks.
@AchmadFathoni commented on GitHub (May 2, 2025):
Something like xz should not be impossible
@josephernest commented on GitHub (May 6, 2025):
Someone reported this 2 hours ago: https://github.com/ventoy/PXE/issues/106
TL;DR:
download of official "iventoy-1.0.20-win64-free.zip"
extraction of
iventoy.datconversion back to
iventoy.dat.xzthanks to @ppatpat's Python codeI confirm that
wintool.tar.xzis recognized by VirusTotal as something that injects fake trusted root certificatesThe next steps are scary:
@0x8008 commented on GitHub (May 7, 2025):
Thanks for giving me yet another reason as to refuse to use this shit.
@ventoy commented on GitHub (May 7, 2025):
Hi everyone, we can discuss this in ##3224
@ventoy commented on GitHub (May 7, 2025):
I close the issue now and we can discuss this in #3224
@no-usernames-left commented on GitHub (May 7, 2025):
"Completed"? Wild.
@ventoy commented on GitHub (May 7, 2025):
This thread is too long, I just open a new issue #3224, let's discuss there.