Yuuuup.

While I wholeheartedly agree this is “meh” compared to everything else, this isn’t nothing.

If you were to try to get a job with even basic security clearance for a site in the US, and it came up that you were hacking at 19 years old, you would not move forward.

It’s a fact-based merit that under normal circumstances would result in termination if it was found to have not been disclosed previously. So pointing it out is still important.

All that being said, disclosure is the key. If it was disclosed, it’s a judgment call, and, well…

Also, @[email protected]

Try WG Tunnel instead. It will reconnect on loss, but you lose the Tailscale features (no big deal with dynamic DNS)

And contribute if you can’t.

For non-programmers: Yes, reporting bugs, writing docs, and answering questions is contributing.

Edit: Fun story, the best contributor I ever had was someone who randomly reproduced reported bugs and filled in the details about how they did it.

Just assume you are.

Thats why I bind toggling them to a hotkey. One or the other at a time, never both.

So maybe use Debian and compile the app yourself instead? The Dev made something free with their time, use your time to make it work for you.

It’s VIM features and key bindings that you can toggle on and off with a hotkey in VScode.

Very handy when you have a task that VIM is better at (for your workflow), like recording s macro and replaying 100 times.

Why not both?

https://github.com/VSCodeVim/Vim

Yes, but…

The build environment was not clean to start, which is why a contributor is working to correct that.

You could also have the build scripts that run on GitHub pull the binary releases directly from their original release locations at build time, vs a file that an individual can modify in the source tree. This isn’t as good as building from source, but it’s better than nothing.

You:

solve a relatively minor security issue.

Wikipedia:

In February 2024, a malicious backdoor was introduced to the Linux build of the xz utility within the liblzma library in versions 5.6.0 and 5.6.1 by an account using the name “Jia Tan”.[b][4] The backdoor gives an attacker who possesses a specific Ed448 private key remote code execution through OpenSSH on the affected Linux system. The issue has been given the Common Vulnerabilities and Exposures number CVE-2024-3094 and has been assigned a CVSS score of 10.0, the highest possible score.[5]

Binary supply-chain attacks are not “minor security issues”. There is a reason many companies will not allow admins to use Ventoy.

I like Ventoy, it’s a fantastic project. I like that the author is transparent about where they won’t be spending their time. You can like a project, and recognize it’s flaws at the same time.

A contributor building a PR to solve the build concerns is not a bad thing, it’s to be celebrated. Even a short-term solution of having the build script pull the binaries from a release and checksum them would alleviate a lot of that concern. And the Windows vs Nix item would be alleviated by the GitHub build ENV. Binary releases isn’t the problem, it’s binary in the source. This is about audits and traceability more than the build itself.

Not having a security first posture on these kinds of attacks is how the xz event happened, and I would hate to see that happen to Ventoy. I look forward to contributors helping the author out.

The problem with Ventoy isn’t the ISOs.

The problem is they use binary versions of core tools like cryptsetup in their source tree, vs compiling them at build time.

This leaves the door open to supply-chain attacks. I.E. a PR with a bad cryptsetup binary, or an attack on crypt that makes its way downstream with no way to audit. This is how huge software distributions make their way to Wikipedia in a bad way: https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor

The solution is the build those binaries at build time, which a fork is working on.

@[email protected]

Oh geez…

I really want to build an ESP32 remote and hub combo with a community-owned device database. I have the know-how, but alas, not the time.

Still using Rufus? Ventoy is the way of the future. One USB, hundreds of ISOs.

Edit: Seems I was unaware of some potential risks with the binary blobs pre-built in Ventoy. No threat has been found, but there are supply-chain concerns. It appears there is a fork where someone is cleaning up the build process.

Maybe, but not based on the sign. That’s a standard trucker joke about waiting for pumps.

Ahhh yes very very true. Also a great addition.

Lemmy is a small place. Dave is friggin moldy. 😉

Name your devices after humans.

Tommy needs larger memory.

I think I’m going to reboot Denise.

I dropped Dave today.

Exactly. I don’t think they’d ever go down this road, but the big players like Samsung have agreements in place where they will continue to get access to main or some trunk. No reason they couldn’t change license and require all players to do the same thing, though O doubt that would happen given the massive security PR implications. So many Android devices would end up with vulnerabilities, tarnishing the image.