My guess is they hastily threw together something hacky in early development, and forgot to replace it with a real, safe solution later.
My guess is they hastily threw together something hacky in early development, and forgot to replace it with a real, safe solution later.
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.
Then, "link to libc". Which libc? glibc? musl?
Yes there is, and you answered in the next line, it is implemented in libc.
If you want to check authentication use libc don't try to implement crypto and authentication yourself.
https://github.com/tailscale/tailscale/blob/e4144230f410204a...
// 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.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.
To clarify: I’m not against CGO, just introducing a glibc dependency by default. I would only introduce it when I needed it.