ci: fix golangci-lint flag for v2 compatibility (#2654)

.github/workflows/lint.yml

@@ -34,7 +34,7 @@ jobs:
 
       - name: golangci-lint
         if: steps.changed-files.outputs.files == 'true'
-        run: nix develop --command -- golangci-lint run --new-from-rev=${{github.event.pull_request.base.sha}} --out-format=colored-line-number
+        run: nix develop --command -- golangci-lint run --new-from-rev=${{github.event.pull_request.base.sha}} --format=colored-line-number
 
   prettier-lint:
     runs-on: ubuntu-latest

CHANGELOG.md

@@ -9,8 +9,7 @@
 
 ### Changes
 
-- Remove policy v1 code
+- Remove policy v1 code [#2600](https://github.com/juanfont/headscale/pull/2600)
-  [#2600](https://github.com/juanfont/headscale/pull/2600)
 - Refactor Debian/Ubuntu packaging and drop support for Ubuntu 20.04.
   [#2614](https://github.com/juanfont/headscale/pull/2614)
 - Support client verify for DERP
@@ -20,8 +19,7 @@
 
 ### Changes
 
-- Ensure nodes are matching both node key and machine key
+- Ensure nodes are matching both node key and machine key when connecting.
-  when connecting.
   [#2642](https://github.com/juanfont/headscale/pull/2642)
 
 ## 0.26.0 (2025-05-14)

README.md

@@ -11,8 +11,8 @@ to ensure you have the correct example configuration. The `main` branch might
 contain unreleased changes. The documentation is available for stable and
 development versions:
 
-* [Documentation for the stable version](https://headscale.net/stable/)
+- [Documentation for the stable version](https://headscale.net/stable/)
-* [Documentation for the development version](https://headscale.net/development/)
+- [Documentation for the development version](https://headscale.net/development/)
 
 ## What is Tailscale
 

docs/about/faq.md

@@ -122,7 +122,6 @@ help to the community.
 
 Running headscale on a machine that is also in the tailnet can cause problems with subnet routers, traffic relay nodes, and MagicDNS. It might work, but it is not supported.
 
-
 ## Why do two nodes see each other in their status, even if an ACL allows traffic only in one direction?
 
 A frequent use case is to allow traffic only from one node to another, but not the other way around. For example, the

docs/ref/dns.md

@@ -9,10 +9,10 @@ Headscale allows to set extra DNS records which are made available via
 [MagicDNS](https://tailscale.com/kb/1081/magicdns). Extra DNS records can be configured either via static entries in the
 [configuration file](./configuration.md) or from a JSON file that Headscale continuously watches for changes:
 
-* Use the `dns.extra_records` option in the [configuration file](./configuration.md) for entries that are static and
+- Use the `dns.extra_records` option in the [configuration file](./configuration.md) for entries that are static and
   don't change while Headscale is running. Those entries are processed when Headscale is starting up and changes to the
   configuration require a restart of Headscale.
-* For dynamic DNS records that may be added, updated or removed while Headscale is running or DNS records that are
+- For dynamic DNS records that may be added, updated or removed while Headscale is running or DNS records that are
   generated by scripts the option `dns.extra_records_path` in the [configuration file](./configuration.md) is useful.
   Set it to the absolute path of the JSON file containing DNS records and Headscale processes this file as it detects
   changes.
@@ -25,7 +25,6 @@ hostname and port combination "http://hostname-in-magic-dns.myvpn.example.com:30
 
     Currently, [only A and AAAA records are processed by Tailscale](https://github.com/tailscale/tailscale/blob/v1.78.3/ipn/ipnlocal/local.go#L4461-L4479).
 
-
 1.  Configure extra DNS records using one of the available configuration options:
 
     === "Static entries, via `dns.extra_records`"

docs/ref/oidc.md

@@ -179,35 +179,43 @@ However if you don't have a domain, or need to add users outside of your domain,
 You can also use `allowed_domains` and `allowed_users` to restrict the users who can authenticate.
 
 ## Authelia
+
 Authelia since v4.39.0, has removed most claims from the `ID Token`, they are still available when application queries [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo).
 
 Following config restores sending 'default' claims in the `ID Token`
 
 For more information please read: [Authelia restore functionality prior to claims parameter](https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter)
 
-
 ```yaml
 identity_providers:
   oidc:
     claims_policies:
       default:
-        id_token: ['groups', 'email', 'email_verified', 'alt_emails', 'preferred_username', 'name']
+        id_token:
+          [
+            "groups",
+            "email",
+            "email_verified",
+            "alt_emails",
+            "preferred_username",
+            "name",
+          ]
     clients:
-      - client_id: 'headscale'
+      - client_id: "headscale"
-        client_name: 'headscale'
+        client_name: "headscale"
-        client_secret: ''
+        client_secret: ""
         public: false
-        claims_policy: 'default'
+        claims_policy: "default"
-        authorization_policy: 'two_factor'
+        authorization_policy: "two_factor"
         require_pkce: true
-        pkce_challenge_method: 'S256'
+        pkce_challenge_method: "S256"
         redirect_uris:
-          - 'https://headscale.example.com/oidc/callback'
+          - "https://headscale.example.com/oidc/callback"
         scopes:
-          - 'openid'
+          - "openid"
-          - 'profile'
+          - "profile"
-          - 'groups'
+          - "groups"
-          - 'email'
+          - "email"
-        userinfo_signed_response_alg: 'none'
+        userinfo_signed_response_alg: "none"
-        token_endpoint_auth_method: 'client_secret_basic'
+        token_endpoint_auth_method: "client_secret_basic"
 ```

docs/ref/routes.md

@@ -1,4 +1,5 @@
 # Routes
+
 Headscale supports route advertising and can be used to manage [subnet routers](https://tailscale.com/kb/1019/subnets)
 and [exit nodes](https://tailscale.com/kb/1103/exit-nodes) for a tailnet.
 
@@ -10,11 +11,13 @@ and [exit nodes](https://tailscale.com/kb/1103/exit-nodes) for a tailnet.
   from a specific IP address.
 
 ## Subnet router
+
 The setup of a subnet router requires double opt-in, once from a subnet router and once on the control server to allow
 its use within the tailnet. Optionally, use [`autoApprovers` to automatically approve routes from a subnet
 router](#automatically-approve-routes-of-a-subnet-router).
 
 ### Setup a subnet router
+
 #### Configure a node as subnet router
 
 Register a node and advertise the routes it should handle as comma separated list:
@@ -31,7 +34,6 @@ $ sudo tailscale set --advertise-routes=10.0.0.0/8,192.168.0.0/24
 
 Finally, [enable IP forwarding](#enable-ip-forwarding) to route traffic.
 
-
 #### Enable the subnet router on the control server
 
 The routes of a tailnet can be displayed with the `headscale nodes list-routes` command. A subnet router with the
@@ -72,6 +74,7 @@ documentation](https://tailscale.com/kb/1019/subnets#use-your-subnet-routes-from
 router on different operating systems.
 
 ### Restrict the use of a subnet router with ACL
+
 The routes announced by subnet routers are available to the nodes in a tailnet. By default, without an ACL enabled, all
 nodes can accept and use such routes. Configure an ACL to explicitly manage who can use routes.
 
@@ -91,18 +94,15 @@ denied.
   "acls": [
     {
       "action": "accept",
-      "src": [
+      "src": ["node"],
-        "node"
+      "dst": ["service.example.net:80,443"]
-      ],
-      "dst": [
-        "service.example.net:80,443"
-      ]
     }
   ]
 }
 ```
 
 ### Automatically approve routes of a subnet router
+
 The initial setup of a subnet router usually requires manual approval of their announced routes on the control server
 before they can be used by a node in a tailnet. Headscale supports the `autoApprovers` section of an ACL to automate the
 approval of routes served with a subnet router.
@@ -114,15 +114,11 @@ owned by the user `alice` and that also advertises the tag `tag:router`.
 ```json title="Subnet routers owned by alice and tagged with tag:router are automatically approved"
 {
   "tagOwners": {
-    "tag:router": [
+    "tag:router": ["alice@"]
-      "alice@"
-    ]
   },
   "autoApprovers": {
     "routes": {
-      "192.168.0.0/24": [
+      "192.168.0.0/24": ["tag:router"]
-        "tag:router"
-      ]
     }
   },
   "acls": [
@@ -141,11 +137,13 @@ Please see the [official Tailscale documentation](https://tailscale.com/kb/1337/
 information on auto approvers.
 
 ## Exit node
+
 The setup of an exit node requires double opt-in, once from an exit node and once on the control server to allow its use
 within the tailnet. Optionally, use [`autoApprovers` to automatically approve an exit
 node](#automatically-approve-an-exit-node-with-auto-approvers).
 
 ### Setup an exit node
+
 #### Configure a node as exit node
 
 Register a node and make it advertise itself as an exit node:
@@ -162,7 +160,6 @@ $ sudo tailscale set --advertise-exit-node
 
 Finally, [enable IP forwarding](#enable-ip-forwarding) to route traffic.
 
-
 #### Enable the exit node on the control server
 
 The routes of a tailnet can be displayed with the `headscale nodes list-routes` command. An exit node can be recognized
@@ -202,8 +199,9 @@ Please refer to the official [Tailscale documentation](https://tailscale.com/kb/
 how to use an exit node on different operating systems.
 
 ### Restrict the use of an exit node with ACL
+
 An exit node is offered to all nodes in a tailnet. By default, without an ACL enabled, all nodes in a tailnet can select
-and use an exit node. Configure `autogroup:internet` in an ACL rule to restrict who can use *any* of the available exit
+and use an exit node. Configure `autogroup:internet` in an ACL rule to restrict who can use _any_ of the available exit
 nodes.
 
 ```json title="Example use of autogroup:internet"
@@ -211,18 +209,15 @@ nodes.
   "acls": [
     {
       "action": "accept",
-      "src": [
+      "src": ["..."],
-        "..."
+      "dst": ["autogroup:internet:*"]
-      ],
-      "dst": [
-        "autogroup:internet:*"
-      ]
     }
   ]
 }
 ```
 
 ### Automatically approve an exit node with auto approvers
+
 The initial setup of an exit node usually requires manual approval on the control server before it can be used by a node
 in a tailnet. Headscale supports the `autoApprovers` section of an ACL to automate the approval of a new exit node as
 soon as it joins the tailnet.
@@ -234,14 +229,10 @@ is automatically approved:
 ```json title="Exit nodes owned by alice and tagged with tag:exit are automatically approved"
 {
   "tagOwners": {
-    "tag:exit": [
+    "tag:exit": ["alice@"]
-      "alice@"
-    ]
   },
   "autoApprovers": {
-    "exitNode": [
+    "exitNode": ["tag:exit"]
-      "tag:exit"
-    ]
   },
   "acls": [
     // more rules
@@ -272,6 +263,7 @@ availability](https://tailscale.com/kb/1115/high-availability#subnet-router-high
     interruptions for clients. See [issue 2129](https://github.com/juanfont/headscale/issues/2129) for more information.
 
 ## Troubleshooting
+
 ### Enable IP forwarding
 
 A subnet router or exit node is routing traffic on behalf of other nodes and thus requires IP forwarding. Check the