It still makes me jittery how much stuff they've packed into the client. The RCE vulnerability in their windows client is pretty strong indicator that things are moving a bit too fast for comfort.
My fortinet footprint would like to assure you that stuff which moves slowly also has problems. I try not to hold a CVE against anyone unless they are extremely stupid and reveal a lack of any technical controls.
wireguard is a linux-first solution and all of the windows stuff for it is subgrade, and probably will continue to be for awhile. Still selling plenty of anyconnect/globalprotect have a stranglehold on windowsland and probably will for a long time.
To be fair, the exploit chain was rather complex. Had it been more straight forward I'd be worried, but with the amount of pivoting required to make the exploit work it seems more like something even a security conscious developer could miss.
Agreed: I do feel the Windows client in particular is a little scary. In general, Tailscale clients feel reasonable, if light; but the Windows client is kind of iffy. There's a bug that I believe still exists where on some machines, it will crash on startup most of the time, seemingly the result of a race condition or other bug where GetLastError returns something unexpected, in a not-very-well maintained Win32 API wrapping library for Go. This is mostly benign (although annoying) but the contrast in how competent Tailscale seems to be about the core guts vs the clients feels a little jarring at times! Still love it though.
FWIW, we've recently taken over maintenance of those Go libraries because they seem to have been abandoned upstream. And we now have people working on Windows full-time. (Early on, the Tailscale team was all primarily Linux and macOS users so Windows was admittedly neglected for too long)
There were a few things going on with that issue you mentioned; one of them is the way the wrapper library was written, the other was with some stuff in the GUI client that was happening on a background goroutine but shouldn't have been. That should be fixed in the current stable release.
As for the Windows client in general, it is going to be receiving a lot of love over the next few months!
I see; I need to update the client on one of my machines. I appreciate the heads up, as it is quite frustrating to get it to start sometimes. Thanks!
I'll have to check out the bug sometime, but it sounds like it's just bad luck with goroutine scheduling and the order things execute in, in a goroutine that isn't locked to a thread. I can see it going unnoticed on older versions of Go (especially prior to weirder things like usermode preemption.)
