I'd rather live through my 80s without much struggling. Longevity and quality of life until the end. And I try to live in the way that lends itself towards that.
If it used one of the standard system APIs for looking up user accounts (e.g. getpwnam(3)), there's no way it can happen.
This is incredibly bad engineering, on level of a SQL injection, in 21st century. Something a highschool student experimenting with scripting could come up with, but not a supposedly professional software company.
The proper fix would be to not use getent CLI tool in their logic, but instead use proper system APIs for looking up user account entries, like one of earlier comments here already mentions. This is shocking amateur hour!
My guess is they hastily threw together something hacky in early development, and forgot to replace it with a real, safe solution later.
The issue here is there is NO single system API for looking up user account entries on Linux.
It's implemented in libc. So you need to link to libc. Tailscale is a Go binary, and they probably prefer it to be statically-linked. glibc NSS implementation also REQUIRES you to load `.so` so you just can't emulate it in Go.
But of course there is, it's part of POSIX, implemented in libc. And if you're using a higher level language, they all have their own wrappers around libc/POSIX APIs. Here is golang's: https://pkg.go.dev/os/user
// userLookupGetent uses "getent" to look up users so that even with static
// tailscaled binaries without cgo (as we distribute), we can still look up
// PAM/NSS users which the standard library's os/user without cgo won't get
// (because of no libc hooks). If "getent" fails, userLookupGetent falls back
// to the standard library.
Others have pointed out that os/user.Lookup is a platform-independent way to resolve this, but additionally you don’t _need_ to link against glibc to use it.
If you are writing go, you usually want to set CGO_ENABLED=0 by default, to avoid inadvertently introducing nonportable code. In this way, only the pure Go implementations are used and there is no need to link (statically or dynamically) against a libc implementation to compile and run your programs.
Unless you're trying to do something like high frequency stock trading, this does not really matter. Most of the added latency is added in the hops themselves, as packets are being classified and routed. Your generic Internet user won't be able to see any difference.
I have the exact opposite experience with Anki. I use it to memorize vocabulary of a language I'm learning, a language completely different to other languages I know, and my retention before and after I started using Anki is night and day. Frankly, I was floored once I realized how much faster I was learning, and how easily I can recall even words I last practiced or used months ago.
I make and maintain my own cards/notes, which I think is part of why it works so well - it's tailored to my learning, not to someone else's.
Well, I should have qualified my statement: Anki is inefficient compared to better methods, but more efficient than haphazardly trying to memorize things. Yes, it's better than nothing, but there are better SRS implementations, including most readers.
I saw a lot of this from personal experience. I had to learn not only Latin and Greek, but also French and German just for my doctorate, and I learned Russian, Thai, and Swedish separately. And then I taught Latin and Greek for years, inquiring often how my students were learning. Anki (vel sim.) is fine, but there are better ways (and none of those ways start with the letter D and end with the letters lingo).
That's because Unified Attestation is unsalvageable. It's basically the same scam as Google's, with different owners doing (or wanting to do) the extortion.
I'd like to point out that it only "gets pulled in" if the data is actually made available by the government, and there are dedicated volunteers who work on getting the data, massaging it into the right format and importing it into OSM, and that is not the case in many countries.
reply