Anybody using that one old, unreleased version of Tailscale from over
a year ago should've rebooted their machine by now to get various
non-Tailscale security updates. :)
Change-Id: If9e043cb008b20fcd6ddfd03756b3b23a9d7aeb5
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
So js/wasm clients can log in for a bit using regular Gmail/GitHub auth
without using an ephemeral key but still have their node cleaned up
when they're done.
Updates #3157
Change-Id: I49e3d14e9d355a9b8bff0ea810b0016bfe8d47f2
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
The image is pulled using tailscale/tailscale:latest, and can be run using tailscale/tailscale
Signed-off-by: Michael Stapelberg <michael@stapelberg.de>
Temporary measure until we switch to Go 1.18.
$ go run ./cmd/tailscale version
1.17.0-date.20211022
go version: go1.17
Updates #81
Change-Id: Ic82ebffa5f46789089e5fb9810b3f29e36a47f1a
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Complete with converters to all the other types that represent a
node key today, so the new type can gradually subsume old ones.
Updates #3206
Signed-off-by: David Anderson <danderson@tailscale.com>
So future refactors can only deal with a net.Listener and
be unconcerned with their caller's (Windows-specific) struggles.
Change-Id: I0af588b9a769ab65c59b0bd21f8a0c99abfa1784
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
I'll keep ipnserver.Run for compatibility, but it'll be a wrapper
around several smaller pieces. (more testable too)
For now, start untangling some things in preparation.
Plan is to have to have a constructor for the just-exported
ipnserver.Server type that takes a LocalBackend and can
accept (in a new method) on a provided listener.
Change-Id: Ide73aadaac1a82605c97a2af1321d0d8f60b2a8c
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
It's all opaque, there's no constructor, and no exported
methods, so it's useless at this point, but this is one
small refactoring step.
Change-Id: Id961e8880cf0c84f1a0a989eefff48ecb3735add
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Now that we multicast the SSDP query, we can get IGD offers from
devices other than the current device's default gateway. We don't want
to accidentally bind ourselves to those.
Updates #3197
Signed-off-by: David Anderson <danderson@tailscale.com>
So js/wasm can override where those go, without implementing
an *os.File pipe pair, etc.
Updates #3157
Change-Id: I14ba954d9f2349ff15b58796d95ecb1367e8ba3a
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
And the derper change to add a CORS endpoint for latency measurement.
And a little magicsock change to cut down some log spam on js/wasm.
Updates #3157
Change-Id: I5fd9e6f5098c815116ddc8ac90cbcd0602098a48
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Otherwise random browser requests to /derp cause log spam.
Change-Id: I7bdf991d2106f0323868e651156c788a877a90d5
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
There are /etc/resolv.conf files out there where resolvconf wrote
the file but pointed to systemd-resolved as the nameserver.
We're better off handling those as systemd-resolved.
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
> # 127.0.0.53 is the systemd-resolved stub resolver.
> # run "systemd-resolve --status" to see details about the actual nameservers.
Fixes https://github.com/tailscale/tailscale/issues/3026
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
In some containers, /etc/resolv.conf is a bind-mount from outside the container.
This prevents renaming to or from /etc/resolv.conf, because it's on a different
filesystem from linux's perspective. It also prevents removing /etc/resolv.conf,
because doing so would break the bind-mount.
If we find ourselves within this environment, fall back to using copy+delete when
renaming to /etc/resolv.conf, and copy+truncate when renaming from /etc/resolv.conf.
Fixes#3000
Co-authored-by: Denton Gentry <dgentry@tailscale.com>
Signed-off-by: David Anderson <danderson@tailscale.com>
Just something I ran across while debugging an unrelated failure. This
is not in response to any bug/issue.
Signed-off-by: Maisem Ali <maisem@tailscale.com>
