141–150 of 157 posts
Earlier quoted context omitted.
“--“ doesn’t work on all versions of getent. A better fix is to call “getent passwd” with no user controlled arguments and then parse the resulting list. This gets rid of the input sanitization problem entirely.
Are there any actual systems that can run Tailscale and that have faulty getent?
Earlier quoted context omitted.
> And we only use Tailscale as a glorified VPN, we don't use their hundreds of extra random features like this SSH one. Same, you are not alone. The Tailscale VPN stuff just works. None of their competitors can claim this that I'm aware of. We tried several other products and none of them were as reliable and 'just worked'. I imagine they spend a lot of time just keeping that stuff working.
Tailscale on iOS has always been highly unreliable for me, while the regular Wireguard app just works.
Earlier quoted context omitted.
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. Then, "link to libc". Which libc? glibc? musl?
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
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.Earlier quoted context omitted.
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. Then, "link to libc". Which libc? glibc? musl?
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 implement…
Earlier quoted context omitted.
Tailscale on iOS has always been highly unreliable for me, while the regular Wireguard app just works.
Interesting! I use it only occasionally, but I don't leave the connection on. I only turn the iOS Tailscale connection on when I need to access resources behind Tailscale. Are you having issues with it when it's always connected?
Meanwhile with wireguard: It just works. Every time. Every where. Unless someone blocks UDP.
Earlier quoted context omitted.
> And we only use Tailscale as a glorified VPN, we don't use their hundreds of extra random features like this SSH one. Same, you are not alone. The Tailscale VPN stuff just works. None of their competitors can claim this that I'm aware of. We tried several other products and none of them were as reliable and 'just worked'. I imagine they spend a lot of time just keeping that stuff working.
Tailscale on iOS has always been highly unreliable for me, while the regular Wireguard app just works.
Its better than it used to be.
But the fundamental problem is that the Wireguard app is a simple GUI around `wireguard-go` built as a static C library via cgo. But Tailscale uses a fork of `wireguard-go` and then adds control client, DERP, NAT traversal etc. on top of it.
So there's quite a lot of "bloat" on top of the Wireguard code in Tailscale iOS and therefore your problem might not be Wireguard vs Wireguard implementation question but something happening elsewhere in the Tailscale code.
Earlier quoted context omitted.
Interesting! I use it only occasionally, but I don't leave the connection on. I only turn the iOS Tailscale connection on when I need to access resources behind Tailscale. Are you having issues with it when it's always connected?
It randomly and frequently turns off, then the connected services of course no longer work, then you turn it on manually, they still don’t work, then you hard kill safari a few times and/or toggle it on and off and it eventually works. On Linux or Windows the client is rock-solid however. Meanwhile with wireguard: It just works. Every time. Every where. Unless someone blocks UDP.
Earlier quoted context omitted.
Good point. I self host headscale but it also has the ssh feature, probably also insecure.
Not necessarily, it's a clean room implementation. Even if leading dashes was known/documented/tested to implement they might have done it differently. And maybe it was an implementation detail that it was ever allowed, but that's a weird username, headscale implementation happened not to allow it, and nobody ever noticed the discrepancy.
This project is not associated with Tailscale Inc.
However, one of the active maintainers for Headscale is employed by Tailscale and he is allowed to spend work hours contributing to the project. Contributions from this maintainer are reviewed by other maintainers.
Earlier quoted context omitted.
Because it breaks our mental model of how things work.
Or it means it is time to update the model. Models need to change as the world they model changes, right?
Instead, they just sneaked the change upon the world.