I really liked the giant pretzels at a brewery near me. Sat near the kitchen until I saw the box they pulled them out of. Learned I could buy 75 online for the price of 5 there.

Wow, all the down votes. Youngin’s don’t know what they’re missing. Classic film.

Nigel Farage admitted he would allow American chlorine-washed chicken

Annnnd there you have it.

@[email protected] @[email protected]

You can post screenshots of tweets no matter when they were taken or how old they are

So, anyone forking and setting it up with ntfy.sh?

But not FOSS like LS unfortunately

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…