Our `socket-factory`-aware HttpClient is currently only able to handle a
single request at a time. That is a result of the requirement that we
wanted to support connections to different domains but also be able to
"self-heal" those connections by establishing a new one if the current
one failed.
As I am learning more about how connlib's DoH support is going to work,
it became apparent that we will only ever need to connect to a single
domain per instance of the `HttpClient`. In addition, it is quite
important to allow for concurrent requests: We don't want to process DoH
queries in sequence but instead make full use of the underlying HTTP2
protocol and send multiple requests in parallel.
This PR refactors the `HttpClient` (which isn't in use anywhere yet) to
only support a single connection per instance. That connection is
established when the instance is created. This is also conceptually
easier to understand as we only manage a single connection without
mutable state.
Related: #4668
In order to support multiple different protocols of upstream DNS
resolvers, we deprecate the `upstream_dns` field in the client's `init`
message and introduce two new fields:
- `upstream_do53`
- `upstream_doh`
For now, only `upstream_do53` is populated and `upstream_doh` is always
empty.
On the client-side, we for now only introduce the `upstream_do53` field
but fall-back to `upstream_dns` if that one is empty. This makes this PR
backwards-compatible with the portal version that is currently deployed
in production. Thus, this PR can be merged even prior to deploying the
portal.
Internally, we prepare connlib's abstractions to deal with different
kinds of upstreams by renaming all existing "upstream DNS" references to
`upstream_do53`: DNS over port 53. That includes UDP as well as TCP DNS
resolution.
Resolves: #10791
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Bumps
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
from 24.5.2 to 24.7.2.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
from 24.5.2 to 24.7.2.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
In #10817, we landed a fix that allows Clients to re-resolve the portal
URL every time the WebSocket connection fails. Currently, we use the
active upstream resolvers for this.
This can lead to a kind of deadlock in case the upstream resolver is a
CIDR resource that we are not yet connected to. In that case, we'd need
a connection to the portal to establish a connection to the Gateway.
By always using the system resolvers for this, we avoid this circular
dependency.
By default, DNS queries are sent over UDP by most systems. UDP is an
easy to understand protocol because each packet stands by itself and at
least as far as UDP is concerned, the payload is contained within a
single packet.
In Firezone, we receive all DNS traffic on the TUN device as IP packets.
Processing the UDP packets is trivial as each query is contained within
a single IP packet. For TCP, we first need to assemble the TCP stream
before we can read the entire query.
In case a DNS query is not for a Firezone DNS resource, we want to
forward it to the specified upstream resolver, either directly from the
system or - in case the specified upstream resolver is an IP resource -
through the tunnel as an IP packet. Specifically, the forwarding of UDP
DNS packets through the tunnel currently happens like this:
IP packet -> read UDP payload -> parse DNS query -> mangle original
destination IP to new upstream -> send through tunnel
For TCP DNS queries, it is not quite as easy as we have to decode the
incoming TCP stream first before we can parse the DNS query. Thus, when
we want to then forward the query, we need to open our own TCP stream to
the upstream resolver and encode the DNS query onto that stream, sending
each IP packet from the TCP client through the tunnel.
The difference in these designs makes several code paths in connlib hard
to follow.
Therefore - and despite the simplicity of DNS over UDP - we already
created our own "Layer 3 UDP DNS"-client. This PR now integrates this
client into the tunnel. Using this new client, we can simplify the
processing of UDP DNS queries because we never have to "go back" to the
original IP packet. Instead, when a DNS query needs to be forwarded to
an usptream resolver through the tunnel, we simply tell the Layer 3 UDP
DNS client to make a new DNS query. The processing of the resulting IP
packet then happens in a different place, right next to where we also
process the IP packets of the TCP DNS client.
That simplifications unlocks further refactorings where we now only
process DNS queries in a single place and the transport we received it
over is a simple function parameter with the control flow for both of
them being identical.
Related: #4668
Currently, the DNS records for the portal's hostname are only resolved
during startup. When the WebSocket connection fails, we try to reconnect
but only with the IPs that we have previously resolved. If the local IP
stack changed since then or the hostname now points to different IPs, we
will run into the reconnect-timeout configured in `phoenix-channel`.
To fix this, we re-resolve the portal's hostname every time the
WebSocket connection fails. For the Gateway, this is easy as we can
simply reuse the already existing `TokioResolver` provided by hickory.
For the Client, we need to write our own DNS client on top of our socket
factory abstraction to ensure we don't create a routing loop with the
resulting DNS queries. To simplify things, we only send DNS queries over
UDP. Those are not guaranteed to succeed but given that we do this on
every "hiccup", we already have a retry mechanism. We use the currently
configured upstream DNS servers for this.
Resolves: #10238
Now that we have an APT repository for Debian / Ubuntu packages, we
should also tell our users about it. We introduce a new "Debian /
Ubuntu" tab on the deployments screen in the portal. The tab is selected
by default as it should provide the best user experience for manually
deployed Gateways:
- Updates are as easy as `sudo apt upgrade`
- The systemd file and token are fully managed in the background
Here is what the new tab looks like:
<img width="679" height="786" alt="image"
src="https://github.com/user-attachments/assets/da69fc55-6a6a-476d-bed4-634dd05df8bc"
/>
Resolves: #10701
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Bumps
[fast-xml-parser](https://github.com/NaturalIntelligence/fast-xml-parser)
from 5.2.5 to 5.3.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/NaturalIntelligence/fast-xml-parser/blob/master/CHANGELOG.md">fast-xml-parser's
changelog</a>.</em></p>
<blockquote>
<p><!-- raw HTML omitted -->Note: If you find missing information about
particular minor version, that version must have been changed without
any functional change in this library.<!-- raw HTML omitted --></p>
<p><strong>5.3.1 / 2025-11-03</strong></p>
<ul>
<li>Performance improvement for stopNodes (By <a
href="https://github.com/macieklamberski">Maciek Lamberski</a>)</li>
</ul>
<p><strong>5.3.0 / 2025-10-03</strong></p>
<ul>
<li>Use <code>Uint8Array</code> in place of <code>Buffer</code> in
Parser</li>
</ul>
<p><strong>5.2.5 / 2025-06-08</strong></p>
<ul>
<li>Inform user to use <a
href="https://github.com/NaturalIntelligence/fxp-cli">fxp-cli</a>
instead of in-built CLI feature</li>
<li>Export typings for direct use</li>
</ul>
<p><strong>5.2.4 / 2025-06-06</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/747">#747</a>):
fix EMPTY and ANY with ELEMENT in DOCTYPE</li>
</ul>
<p><strong>5.2.3 / 2025-05-11</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/747">#747</a>):
support EMPTY and ANY with ELEMENT in DOCTYPE</li>
</ul>
<p><strong>5.2.2 / 2025-05-05</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/746">#746</a>):
update strnum to fix parsing issues related to enotations</li>
</ul>
<p><strong>5.2.1 / 2025-04-22</strong></p>
<ul>
<li>fix: read DOCTYPE entity value correctly</li>
<li>read DOCTYPE NOTATION, ELEMENT exp but not using read values</li>
</ul>
<p><strong>5.2.0 / 2025-04-03</strong></p>
<ul>
<li>feat: support metadata on nodes (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/593">#593</a>)
(By <a href="https://github.com/srl295">Steven R. Loomis</a>)</li>
</ul>
<p><strong>5.1.0 / 2025-04-02</strong></p>
<ul>
<li>feat: declare package as side-effect free (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/738">#738</a>)
(By <a href="https://github.com/tbouffard">Thomas Bouffard</a>)</li>
<li>fix cjs build mode</li>
<li>fix builder return type to string</li>
<li></li>
</ul>
<p><strong>5.0.9 / 2025-03-14</strong></p>
<ul>
<li>fix: support numeric entities with values over 0xFFFF (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/726">#726</a>)
(By <a href="https://github.com/mcdurdin">Marc Durdin</a>)</li>
<li>fix: update strnum to fix parsing 0 if skiplike option is used</li>
</ul>
<p><strong>5.0.8 / 2025-02-27</strong></p>
<ul>
<li>fix parsing 0 if skiplike option is used.
<ul>
<li>updating strnum dependency</li>
</ul>
</li>
</ul>
<p><strong>5.0.7 / 2025-02-25</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/724">#724</a>)
typings for cjs.</li>
</ul>
<p><strong>5.0.6 / 2025-02-20</strong></p>
<ul>
<li>fix cli output (By <a href="https://github.com/angeld7">Angel
Delgado</a>)
<ul>
<li>remove multiple JSON parsing</li>
</ul>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="badf18960c"><code>badf189</code></a>
Use <code>Uint8Array</code> in place of <code>Buffer</code> in
Parser</li>
<li><a
href="418ab9535c"><code>418ab95</code></a>
fix <a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/764">#764</a>
(<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/765">#765</a>)</li>
<li><a
href="ad17aa4b12"><code>ad17aa4</code></a>
Fix typo in types (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/760">#760</a>)</li>
<li>See full diff in <a
href="https://github.com/NaturalIntelligence/fast-xml-parser/compare/v5.2.5...v5.3.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [nu-ansi-term](https://github.com/nushell/nu-ansi-term) from
0.50.1 to 0.50.3.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/nushell/nu-ansi-term/commits">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The current CI job expects the release to have the `.deb` files
attached. Since writing that workflow, I've changed my mind on attaching
the `.deb` files there. Instead, they are only uploaded to the
repository. Without documentation on how to use them, these `.deb` files
are unlikely to provide a good user experience.
We change the job to instead promote the latest "preview` archives to
the stable repo.
By default, the Sentry SDK doesn't include custom user attributes when
it sends logs. To make viewing logs easier, we add the `account_slug`
attribute to all logs that are posted to Sentry.
All of our Linux applications have a soft-dependency on systemd. That
is, in the default configuration, we expect systemd to be present on the
machine. The only exception here are the docker containers for Headless
Client and Gateway.
For the GUI client in particular, systemd is a hard-dependency in order
to control DNS on the system which we do via `systemd-resolved`. To
secure the communication between the GUI client and its tunnel process,
we automatically create a group called `firezone-client` to which the
user gets added. All members of the group are allowed to access the unix
socket which is used for IPC between the two processes. Membership in
this group is also a prerequisite for accessing any of the configuration
files.
On the first launch of the GUI client on a Linux system, this presents a
problem. For group membership changes to take the effect, the user needs
to reboot. We say that in the documentation but it is unclear whether
all users will read that thoroughly enough. To help the user, the GUI
client checks for membership of the current user in the group and alerts
the user via a dialog box if that isn't the case. This would all be fine
if it would actually work. Unfortunately, that check ends up being too
late in the process. If we aren't a member of the group, we cannot read
the device ID and bail early, thus never reaching the check and
terminating the process without any dialog box or user-visible error.
We could attempt to fix this by shuffling around some of the startup
init code. That is a sub-optimal solution however because it a) may get
broken again in the future and b) it means we have to delay
initialisation of telemetry until a much later point.
Given that this is only a problem on Linux, a better solution is to
simply not rely on the disk-based device ID at all. Instead, we can
integrate with systemd and deterministically derive a device ID from the
unique machine ID and a randomly chosen "app ID".
For backwards-compatibility reasons, the disk-based device ID is still
prioritised. For all new installs however, we will use the one based on
`/etc/machine-id`.
When we are building the log message that is sent to Sentry, we append
several attributes to mimic the formatting that we get from
`tracing_subscriber::fmt`. To do that, we strip the span name from the
attribute which can result in us processing the same attribute such as
`cid` twice: Once from a span and once from the actual log message. In
order to not append the same message twice, we check for its presence in
the attributes map first.
This avoids having message in Sentry such as:
```
Sampled relay cid=c18e1da8-8ef8-4e11-a325-28d6b387d503 rid=3af15c76-9e84-46a6-90e1-63ecb2bc9f80 cid=c18e1da8-8ef8-4e11-a325-28d6b387d503
```
When investigating, why a connection fails it is useful to know right
away, what the last connection state was, including the kind of
connection, such as `PeerToPeer`, `RelayToPeer` etc.
Sentry appends "breadcrumbs" to every error that gets sent to the
backend. By default, those include the last 500 DEBUG logs. Our
`phoenix_channel` module logs the incoming and outgoing messages on
TRACE using the `wire::api::send` and `wire::api::recv` targets.
To make debugging these easier, we always include anything on
`wire::api` in the breadcrumbs.
The current test installation fails because it is operating in a
headless environment without a display user. Some more testing of the
`who` command showed that we can simply take the first user. That avoids
`grep` which was previously failing with an exit code of 1, aborting the
installation because our `postinst` script has `pipefail` set.
Specifying `sudo` in the script is unnecessary as it already runs as
root. Additionally, only executing `systemd-sysusers` for our config
file is better because it narrows the scope of what should be done.
Several aspects of the Gateway's Debian package depend on `systemd`
being present. Without it, we don't have the necessary users and files
in place for the Gateway to function. With that specified, we can fail
the `postinst` script (and therefore the installation) if anything in
there goes wrong.
By checking various environment variables, we can automatically add the
current user to the `firezone-client` group which allows them to connect
to the IPC socket of the tunnel process. Unfortunately, they still have
to create a new login session / reboot for that to be reflected.
The docs update for this will follow once we have cut a release with
this code in it.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Prompted by Xcode warning at project startup.
Most of the changes are simple migrations from entitlements files
to build settings, which is the recommended approach, and were done
automatically by Xcode.
new settings:
- REGISTER_APP_GROUPS - Automatically registers app groups with
provisioning
profile (I had to set this manually when setting up, so it's a welcome
change)
- STRING_CATALOG_GENERATE_SYMBOLS - type-safe localization (no
regression, we're not doing any localization currently)
- ENABLE_USER_SCRIPT_SANDBOXING - sandboxing all the build scripts
Note: I had to turn off the recommended `ENABLE_USER_SCRIPT_SANDBOXING`
as it
would interfere with our building of connlib during the build.
Also: make Makefile more ergonomic to use (setup LSP config during first
build)
For DNS resources, the Gateway maintains a per-peer NAT table from the
client-assigned proxy IPs to the real IPs of the domain. Whenever the
Client re-queries a DNS resource domain locally, we asynchronously ping
the Gateway to also re-query said domain. This allows us to detect
changes in the DNS records of DNS resources.
To avoid breaking existing connections, the mapping between proxy IPs
and real IPs is currently not updated if there are any active UDP or TCP
flows for a proxy IP.
This logic turns out to be unnecessarily restrictive as TCP flows can
linger around for up to 2h before they timeout if they are not closed
with a TCP RST. What we really need to do is always update the mapping
of proxy IP <> real IP but honor existing NAT table entries when we
route packets before creating new ones. This ensures that an existing
connection to a previously resolved IP remains intact, even if a later
DNS response for the same domain updates the mapping. At the same time,
new connections (i.e. with a different source port) will immediately use
the new destination IP.
Refactors IPCClient from an actor to a stateless enum with static
methods, removing unnecessary actor isolation and instance management.
- IPCClient: Actor → enum with static methods taking session parameter
- Store: Removed IPCClient instance caching, added resource list caching
- Store: Moved resource fetching logic from IPCClient into Store
- All call sites: Updated to pass session directly to static methods
Store now directly manages resource list hashing and caching via
fetchResources() method, using SHA256 hash optimisation to avoid
redundant updates when resource lists haven't changed.
Enables SWIFT_APPROACHABLE_CONCURRENCY build setting which activates
a few key Swift 6.2 concurrency features, including:
1. NonisolatedNonsendingByDefault - Makes nonisolated async functions
run
on the caller's executor instead of the global executor, providing
more predictable performance and behaviour
2. InferIsolatedConformances - Protocol conformances automatically
inherit global actor isolation, reducing annotation burden
Read more:
https://www.donnywals.com/what-is-approachable-concurrency-in-xcode-26/
Also bumps swift-tools-version from 6.0 to 6.2 in Package.swift to
enable newer Package Manager manifest APIs.
As a result of better type inference, removes 1 redundant @Sendable
annotation in Store.swift:
- vpnStatusChangeHandler: @MainActor closures are implicitly Sendable
This PR upgrades the Swift client from Swift 5 to Swift 6.2, addressing
all
concurrency-related warnings and runtime crashes that come with Swift
6's
strict concurrency checking.
## Swift 6 Concurrency Primer
**`actor`** - A new reference type that provides thread-safe, serialised
access to mutable state. Unlike classes, actors ensure that only one
piece of
code can access their mutable properties at a time. Access to actor
methods/properties requires await and automatically hops to the actor's
isolated executor.
**`@MainActor`** - An attribute that marks code to run on the main
thread.
Essential for UI updates and anything that touches UIKit/AppKit. When a
class/function is marked @MainActor, all its methods and properties
inherit
this isolation.
**`@Sendable`** - A protocol indicating that a type can be safely passed
across concurrency domains (between actors, tasks, etc.). Value types
(structs, enums) with Sendable stored properties are automatically
Sendable.
Reference types (classes) need explicit @unchecked Sendable if they
manage
thread-safety manually.
**`nonisolated`** - Opts out of the containing type's actor isolation.
For
example, a nonisolated method in a @MainActor class can be called from
any
thread without await. Useful for static methods or thread-safe
operations.
**`@concurrent`** - Used on closure parameters in delegate methods.
Indicates
the closure may be called from any thread, preventing the closure from
inheriting the surrounding context's actor isolation. Critical for
callbacks
from system frameworks that call from background threads.
**Data Races** - Swift 6 enforces at compile-time (and optionally at
runtime)
that mutable state cannot be accessed concurrently from multiple
threads. This
eliminates entire classes of bugs that were previously only caught
through
testing or production crashes.
## Swift Language Upgrade
- **Bump Swift 5 → 6.2**: Enabled strict concurrency checking throughout
the
codebase
- **Enable ExistentialAny (SE-0335)**: Adds compile-time safety by
making
protocol type erasure explicit (e.g., any Protocol instead of implicit
Protocol)
- **Runtime safety configuration**: Added environment variables to log
concurrency violations during development instead of crashing, allowing
gradual migration
## Concurrency Fixes
### Actor Isolation
- **TelemetryState actor** (Telemetry.swift:10): Extracted mutable
telemetry
state into a dedicated actor to eliminate data races from concurrent
access
- **SessionNotification @MainActor isolation**
(SessionNotification.swift:25):
Properly isolated the class to MainActor since it manages UI-related
callbacks
- **IPCClient caching** (IPCClient.swift): Fixed actor re-entrance
issues and
resource hash-based optimisation by caching the client instance in Store
### Thread-Safe Callbacks
- **WebAuthSession @concurrent delegate** (WebAuthSession.swift:46): The
authentication callback is invoked from a background thread by
ASWebAuthenticationSession. Marked the wrapper function as @concurrent
to
prevent MainActor inference on the completion handler closure, then
explicitly hopped back to MainActor for the session.start() call. This
fixes EXC_BAD_INSTRUCTION crashes at _dispatch_assert_queue_fail.
- **SessionNotification @concurrent delegate**
(SessionNotification.swift:131): Similarly marked the notification
delegate
method as @concurrent and used Task { @MainActor in } to safely invoke
the
MainActor-isolated signInHandler
### Sendable Conformances
- Added Sendable to Resource, Site, Token, Configuration, and other
model
types that are passed between actors and tasks
- **LogWriter immutability** (Log.swift): Made jsonData immutable to
prevent
capturing mutable variables in @Sendable closures
### Nonisolated Methods
- **Static notification display** (SessionNotification.swift:73): Marked
showSignedOutNotificationiOS() as nonisolated since it's called from the
Network Extension (different process) and only uses thread-safe APIs
Fixes#10674Fixes#10675
Firezone's ability to tunnel all traffic on a particular Client (i.e.
the Internet Resource) means we have to ensure that traffic originating
from within the Firezone process does not get routed back into the
tunnel. On MacOS and iOS, this is automatically taken care of for us. On
all other platforms, we need to take steps to prevent these routing
loops.
This functionality is abstracted away using our `SocketFactory`. A
socket created with such a factory is guaranteed to route its traffic
outside of the tunnel. These sockets are used for the WebSocket
connection to the portal, as well as for recursive UDP and TCP DNS
queries.
In order to support DoH, we need to also be able to send HTTPS requests
without causing packet loops.
This PR adds a new crate `http-client` that does exactly that. It
composes together `hyper` and `rustls` such that the configured
`SocketFactory` is used to create the TCP socket for the underlying
HTTP2 connection. Consequently, HTTPS requests made with this library
will automatically be routed outside of the tunnel, assuming the
`SocketFactory` is adequately configured.
Right now, this crate just stands by itself. It will be integrated into
connlib at a later point.
Resolves: #10774
Related: #4668
Related: #10272
DNS servers are standarised to be contacted on port 53. This is also
hard-coded within `connlib` when we contact an upstream server. As such,
we should disallow users inputting any custom port for upstream DNS
servers. Luckily - or perhaps because it doesn't presently work - no
users in production have actually put in a port.
Resolves: #8330
Within Firezone, there are multiple components that deal with DNS
queries. Two of those components are the `l4-udp-dns-server` and
`l4-tcp-dns-server`. Both of them are responsible for receiving DNS
queries on layer 4, i.e. UDP or TCP. In other words, they do _not_
operate on an IP level (which would be layer 3) but instead use
`UdpSocket` and `TcpListener` to receive queries and sent back
responses.
Right now, the interfaces of these crates are designed for the usecase
of receiving forwarded DNS queries from the CLient on the Gateway's TUN
device. This is a special-case of DNS resolution. When receiving a TXT
or SRV query for a domain that is covered by a DNS resources, Firezone
Client's will forward that query to the corresponding Gateway and
resolve it in its network context. SRV and TXT records are commonly used
for service discovery and as such, should be resolved in the network
context of the service, i.e. the site that assigned to the resource.
For that usecase, it made sense to allow each DNS server to listen on 1
IPv4 and 1 IPv6 address. Since then, our event-loop has evolved a bit,
being able to handle multiple inputs at once. As such, we can simplify
the API of these crates to only listen on a single address and instead
create multiple instances of them inside `Io`. Depending on how the
design of our DNS implementation for the Clients evolves, this may be
used to listen on multiple IPs later (e.g. from the `127.0.0.0/8`
subnet).
Related: #8263
Right now, connlib hands out a `BiMap` of sentinel IPs <> upstream
servers whenever it emits a `TunInterfaceUpdated` event. This `BiMap`
internally uses two `HashMap`s. The iteration order of `HashMap`s is
non-deterministic and therefore, we lose the order in which the upstream
/ system resolvers have been passed to us originally.
To prevent that, we now emit a dedicated `DnsMapping` type that does not
expose its internal data structure but only getters for retrieving the
sentinel and upstream servers. Internally, it uses a `Vec` to store this
mapping and thus retains the original order. This is asserted as part of
our proptests by comparing the resulting `Vec`s.
This fix is preceded by a few refactorings that encapsulate the code for
creating and updating this DNS mapping.
Resolves: #8439
With #8263, we will stop receiving UDP and TCP DNS queries on the tunnel
but use regular sockets instead. This means that for UDP DNS queries
that need to be sent _through_ the tunnel, we actually need to make new
IP packets again. For TCP, we already have a crate that does this for us
because there, we need to manage an entire TCP stack.
For UDP, the story is a bit simpler but there are still a few things
involved. In particular, we need to set a source address for the packets
and we need to sample a new random port for each query.
The crate added in this PR does exactly that. It is not yet used
anywhere but split out into a separate PR to reduce the reviewing burden
of the larger refactor.
Related: #8263
Related: #10758
On Ubuntu, this should be the default anyway and already be installed
but to be correct, we should list this dependency in the `depends`
section of our `.deb`. That way, it will automatically get installed
again if a user chooses to install the GUI client from our repository
and doesn't have `systemd-resolved` installed.
