1,037 karma · joined May 13, 2018
https://en.cppreference.com/w/cpp/filesystem
> The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system.
---
Golang also seems vulnerable to the same issue
https://github.com/golang/go/blob/d15481b8c7f5f73a8b987a0c1d...
Line 78 checks that the path isn't a symlink (time-of-check). Then line 97 calls openFdAt which on line 174 opens the path by name, without NOFOLLOW (time-of-use).
I bet this is a pretty common vulnerability.
Let's say "→" misrepresents the meaning of "->" even as much as 0.1% of the time. Would you rather your risk of error be 99.9%, or 0.1%?
I'm sick of anti-ligature people telling everyone else not to enjoy their fonts, on every single post about a font. Ligatures have caught on for a reason.
Well that's good news, at least
https://www.doc.ic.ac.uk/~mjw03/PersonalWebpage/pdfs/quickso...
This is the kind of thing I hate about "New Windows". Once upon a time MS used to strive for backward compatibility. These days every few years there's a new function you need to call. You can't get optimal behavior just by writing good code from the start. You need to do that, and also call the YesIKnowHowPixelsWork api call, and set <yesIAmCompetent>true</yesIAmCompetent> in your manifest to get what should be the default behavior. It's a mess.
If someone keeps changing their claims or is otherwise acting scummy, just ignore them. There are shysters in every industry.
> Are you sure about this?
Whether I'm sure or not... I think everyone should be given the choice.
If I choose to self-custody, it's much safer to memorize a seed phrase than to store cash in my mattress. Most people don't bother and use banks. But I think it's good that people now have a choice in the matter.
Snap is a nonstarter for me for many reasons. Startup speed is important for shell pipelines, and also it's insane to bundle that much stuff just to run a statically-linked binary. And it wouldn't even solve the version problem, it looks like ripgrep on Snap is two years old. https://snapcraft.io/ripgrep
It looks like manjaro is the most recommended arch distro so I'll give it a try.
> How does scoop solve the problem?
It skips intermediate packaging steps and goes directly to the source. e.g. if the author publishes on GitHub, Scoop will request `github.com/ripgrep/releases/latest` (or whatever) and then download `ripgrep-$version.exe`. It has very primitive dependency handling, but I don't think that matters because I mostly install Go/Rust tools which are statically linked.
I honenstly think it's a genius solution. There's no wait time for updates, and you don't have to trust whatever user created the package on every version update.
I guess that's ironic to hear considering my original question, but I appreciate a different update cadence between the OS (I want LTS, stable) and things like `ripgrep`, which if there's a bug, it won't keep me from booting my system and I can just downgrade if I notice it.
On Windows, you can just `scoop install ripgrep fzf jq` and you're in business. And updating all installed packages is one command away.
Meanwhile on Debian, the system packages are often years out of date. So authors have started making their own custom install scripts [1], or just telling you to `curl` the binary into /usr/bin [2]. To update these manually-curled binaries you need to run a different set of steps for every one. There's no way to list outdated apps, and there's no easy way to update everything.
On top of that, many apps I use aren't even packaged (k9s, broot are two random ones I just found). Sometimes you can find a third-party repo, but that's yet another person you rely on to get updates. Whereas with scoop, it fetches straight from the source, so there's never any waiting.
Is there some alternative to `apt` that everyone is using? Or how do people generally deal with this?