[Backport release-23.11] tailscale: 1.58.2 -> 1.66.4

[06kellyjac]

Description of changes

Resolves: #313678

Backport tailscale updates to resolve security issue.
Also needed to backport go 1.22.

I skipped some cosmetic commits like maintainers being removed, those will be caught up in 24.05

LMK if I've done anything wrong.

Not ran a full build myself yet.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[cole-h]

@ofborg eval

[06kellyjac]

I might need to drop the powerpc stuff

[cole-h]

Maybe, maybe not; the current eval failure is unrelated to your PR's contents:

       error: cannot connect to socket at '/nix/var/nix/gc-socket/socket': No such file or directory

[SuperSandro2000]

We also need to backport #311176 to fix tailscale ssh or just don't backport the combined binary commit.

Also please review and merge the linked PR.

[06kellyjac]

approved, can't merge :)

[06kellyjac]

I've dropped the combine commit for the backport

[Aleksanaa]

@ofborg build tailscale

[risicle]

This is quite a significant bump for stable. Is there no alternative?

[SuperSandro2000]

Technically tailscale is when used together with tailscale.com a software which is tied to an online service like Discord or yt-dlp and those get backported usually.

[06kellyjac]

I'm failing to find the comment on an old update PR but tailscale have a commitment to backwards compatibility and said it should be fine to backport everything unless specified.

I do tend to put backport labels on the PR but the dependency on go 1.22 is a bit of a pain.
I've not seen a standalone patch for this issue. I strongly suspect that with a large update history the patch wouldn't cleanly apply.
It might be possible to modify tailscale to build on 1.21 depending on the features they're using. If 23.11 was going to be alive longer and we couldn't backport 1.22 then I'd potentially consider that.

But with just backporting a security patch to an old release it becomes tricky because you need to fully understand the fix, port that to the older release. It is possible that alone might not be a sufficient fix for the older release, so there's extra validation that you'd ideally want to do. And then there's the matter of identifying that release as fixed which I don't think would happen on the tailscale.com dashboard.

So yeah in this case I think the policy of backporting all updates fits best.

---

Seems like aarch64-darwin go build is busted "no space left on device" could be intermittent?

[risicle]

Regarding upstream claiming everything they release is backwards compatible and backporting security fixes taking extra effort around understanding and testing the fix, you've just described 90% of packages in nixpkgs.

Remember - any changes you make to the stable branch will be "surprise upgrades" for most stable branch users, who will likely have little opportunity for testing before rolling straight into production.

I do wish there were a way for end users to get a better idea what kind of stability to expect from different packages on this front. Something like a meta.stableIsUnstable flag for packages which follow this policy.

[06kellyjac]

There are some upstreams I believe more than others for backwards compatibility promises but I do get your point.
A way to express some more granular policy around maintenance would be good.

[mfrw]

Result of nixpkgs-review pr 313691 run on x86_64-linux 1

3 packages built:

• go_1_22
• tailscale
• trayscale

tested locally

[vcunat]

I'll trust the two meta.maintainers that it's OK. (and ofBorg confirmed it builds on 4 platforms)