tailscale: Tailscale in OpenWrt is vulnerable #24741
Comments
|
The newer version of Tailscale, which includes a security fix, is only available in the daily snapshots of OpenWrt (a5028f2). This is because Tailscale frequently requires the latest versions of Golang (tailscale/tailscale@b6153ef). In the stable version of OpenWrt 23.05, Golang 1.21 is used, and as an open-source project, we are unable to assist this issue. We can propose the following solutions: The developers of the commercial product Tailscale could offer their assistance by releasing OpenWrt packages for stable versions or by providing support and solutions for OpenWrt. Otherwise, Tailscale may be removed from OpenWrt. Lastly, it should be mentioned that tagging multiple irrelevant people on GitHub tends to cause more harm than good. |
|
In my last comment, I forgot to add link to this #24570 (comment) from one of our users, who said that it is not very applicable to typical OpenWrt usage. |
If I'm not mistaken, this could also be related to the reason why Tailscale is not in Debian. Tailscale seems to be made more for rolling release (which is neither Debian nor OpenWrt). As far as I remember, it was said that the Tailscale developers don't want to offer LTS support.
I'm in favor of that too!
Sorry. I'm always unsure when to say or how far back I should go in the commit history - apparently I tend to exaggerate a bit. |
I would prefer not to debate the open-source WireGuard, which is integrated into the Linux kernel, versus the commercial Tailscale, which is a basically paid service and releases updates more frequently. It is true that Tailscale is not included in GNU/Linux distributions, and therefore, we should consider removing this package from OpenWrt as it is gonna solve several issues, which were recently opened (#24712, #24570, #24415, #22003). Based on these two sources, I think it should be clear that it is not possible to keep up with the upstream:
It is beyond our capacity and resources to maintain the latest version of Golang in stable releases, as this increases space requirements and necessitates compatibility with other packages that use Golang. If someone is willing to take on the responsibility, time, and motivation to maintain it, that would be acceptable, but it would contradict the purpose of stable releases. |
|
Could you cite the vulnerability and cite upstream commit that fixes it? Best if xrefd with CVE. |
|
I don't know that either (without further research), as it wasn't included in the tailscale dashboard. |
|
I would understand if Tailscale were to be removed from OpenWrt - but I would still find it a shame. (Well, you can also install it manually - if the router has enough memory). I looked at the changelogs of Tailscale and only found one UPnP vulnerability (TS-2023-006) (or I missed the others). |
I currently manually install Tailscale on Ubiquiti EdgeRouters running EdgeOS. Thanks |
|
Maybe take a look at https://tailscale.com/kb/1053/install-static ?! |
|
Thanks I already use Static Binaries in conjunction with the following installation procedures for EdgeOS. https://github.com/jamesog/tailscale-edgeos I was looking for OpenWrt equivalent installation procedures to use with the Static Binaries. |
You will not find those via bug tracker. Best attempt is to backport tailscale to older Go by reverting ivia a apatch ncompatible dependabot changes upstream. |
@BKPepe Tailscalar here. I'm curious what we could do here. Would you be willing to accept prebuilt binaries from us? We have static builds for Linux available. |
|
@raggi I don't think we could accept prebuilt binaries in OpenWrt. If you would like to ship the static binaries for OpenWrt users, the best possible way is to create a opkg repository. |
That is a fruitless activity. Golang is an absolute bitch about what go version dependencies use. If any dependency bumps their go directive to 1.23, you have some trouble getting it to build. Right now we could downgrade it to golang 1.22, thats the version go mod tidy will write into it but then go build will complains that newer features are used and the build will fail anyway. But doing that is pretty standard for many golang projects and something commonly done. Openwrt could just provide a 2nd go package that has the latest version on stable and the problem is solved. PS: Debian basically has the same problem with golang and rust constantly and stopped shipping the normal Firefox version of that and now you need to fiddle with 3rd party repos or stay on the dated ESR. |
|
Thats only go.mod patch on top of release tarball then? |
|
Well, if no library demands a newer version and no new language features are used, yes, but unfortunately tailscale is already using new features so you would need to rewrite those functions to use the old syntax. |
|
I dont need anything from tailscale, you need the new compiler you make it. |
|
There is already #24992 and that just needs to be backported or copied to stable with a different PKGNAME. |
Why are prebuilt binaries unacceptable? |
Since we are living in AI world, I asked Copilot for that, because it provides the answers which you are looking for. We will not need to discuss all those points, which are there and all of them are really rock solid. Providing stable releases (most likely as LTS) and the development versions makes sense for us, and it will help others, too. |
Every single version of tailscale requires to have up-to-date version of Golang, despite that using our Golang version is supported in upstream. While updating Golang to the latest version, it might break other Go packages due to using unsupported version, yet. We can not also backport recent versions of Golang package to the stable branches as it potentially can break other packages and due to policy of stable branches, there should be backported only security fixes. Based on the upstream issue[^1] and also in Debian's bug report [^2], it is clear that we can not keep up with the upstream. Tailscale can be re-added to this repository, when someone from the community or the tailscale developers steps in and provide support and help while maintaining tailscale in OpenWrt. [^1]: tailscale/tailscale#7847 [^2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972439#19 Fixes: openwrt#24741 Signed-off-by: Josef Schlehofer <[email protected]>
I see Alpine, Gentoo, NixOS, OpenBSD, OpenSuse, VoidLinux to just name a few https://repology.org/project/tailscale/versions |
And Arch. If I'm not mistaken, the reason it wasn't included in Debian is that Debian doesn't provide fast enough updates for Tailscale (according to the Tailscale developers). |
|
Thanks for link, @SuperSandro2000. Have you checked how many of those GNU/Linux distributions have the latest tailscale version? 😇 There is a good exmaple that you can check current OpenWrt versions and against others. |
|
We really should not look at Debian when searching for innovative ideas and to find solutions. Debian has many problems with Go binaries since the beginning due to stupid decisions in their build system (splitting binaries into shared objects) and by using features upstream doesn't really supported. For example docker was severely outdated for ages because of that. Also Debian doesn't support normal versions of browsers on their stable release which are pretty essential in the time we are living.
You mean the 3 EOL versions of alpine and the 4 of nixos the site lists? Probably half of the supported distros have the latest version which is pretty great if I must admit.
that would be pretty easy to fix if there would be go123 or at least go 122 and then we would be rocking. |
Maintainer: @p-w-p @1715173329 @neheb @mochaaP @BKPepe @boretom
Environment: OpenWrt 23.05.4 r24012-d8dd03c46f
Description:
The tailscale version in OpenWrt is vulnerable because it is much too old.
The following message appears in the Tailscale Dashboard:
(It links to https://tailscale.com/kb/1067/update?tab=linux)
Workaround:
The text was updated successfully, but these errors were encountered: