mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
73625e4669adee8df8481caaf9be51ff80094202
6097 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Thomas Eizinger
|
73625e4669 |
chore(relay): don't log all AUTH errors on WARN (#7506)
Not all authentication errors are warnings that we need to be alerted about. |
||
|
Thomas Eizinger
|
5d5e5ab0b1 |
fix(gui-client): make tray menu refresh infallible (#7498)
In most cases, the caller of this function already handled the case of it failing gracefully by logging. From Sentry alerts, we can see that if this fails, there isn't much we can do about it and most likely, the next refresh will work again (this has only happened a single time). Logging this on `debug` is good enough in case something doesn't work and we need to reproduce it or something really bad happens we need see it in the breadcrumbs of another Sentry event. |
||
|
Thomas Eizinger
|
f30cc3226d |
fix(gateway): don't return error when client disconnected (#7504)
When a client disconnects, we clear up the connection on the gateway. There might still be packets arriving from resources that we then cannot route. This isn't worth returning an error. |
||
|
Thomas Eizinger
|
b5d6c27680 |
fix(linux): don't print error when removing non-existent route (#7502)
We are already handling one case where we are trying to remove a route that doesn't exist. `ESRCH` is another variant of this error that manifests as "No such process". According to the Internet, this just means the route doesn't exist so we can bail out early here. |
||
|
Thomas Eizinger
|
30376cd79a |
fix(gateway): polish error handling in main (#7500)
Currently, the Gateway logs all errors that happen when the event-loop exits on ERROR level. This creates Sentry alerts for things like "Unauthorized" errors or "404 Not found". That isn't useful to us. To mitigate this, we polish the code a bit to only log an ERROR when we actually fail to setup something during startup (like the TUN device). In all other cases, we now log a more user-friendly message on INFO but still exit with the appropriate exit code (0 on CTRL+C, 1 on any other error). |
||
|
Thomas Eizinger
|
db2dd4a618 |
ci: pass SENTRY_AUTH_TOKEN explicit as input (#7503)
Secrets are not accessible within actions. |
||
|
Thomas Eizinger
|
951edd802a | fix(gui-client): lower log level when update check fails (#7501) | ||
|
Thomas Eizinger
|
f0c2bfa6eb |
chore(gui-client): release version 1.4.0 (#7496)
GUI Client 1.4.0 has been released (https://github.com/firezone/firezone/releases/tag/gui-client-1.4.0). This PR updates the changelog and versions accordingly. |
||
|
Brian Manifold
|
9711cf56c1 |
fix(portal): Fix update API endpoint for resources (#7493)
Why: * The API endpoint for updating Resources was using `Resources.fetch_resource_by_id_or_persistent_id`, however that function was fetching all Resources, which included deleted Resources. In order to prevent an API user from attempting to update a Resource that is deleted, a new function was added to fetch active Resources only. Fixes: #7492 |
||
|
Thomas Eizinger
|
67161afd2c |
build(deps): switch to quinn-udp release (#7491)
The less Git-dependencies the better. |
||
|
Thomas Eizinger
|
da04924da1 |
chore(relay): downgrade log on missing allocation for REFRESH (#7490)
Attempting to refresh an allocation is the only idempotent way in TURN to test whether one has an active allocation. As such, logging this on WARN is too aggressive. Resolves: #7481. |
||
|
Thomas Eizinger
|
7a478634a8 |
feat(connlib): buffer packets during connection and NAT setup (#7477)
At present, `connlib` will always drop all IP packets until a connection is established and the DNS resource NAT is created. This causes an unnecessary delay until the connection is working because we need to wait for retransmission timers of the host's network stack to resend those packets. With the new idempotent control protocol, it is now much easier to buffer these packets and send them to the gateway once the connection is established. The buffer sizes are chosen somewhat conservatively to ensure we don't consume a lot of memory. The hypothesis here is that every protocol - even if the transport layer is unreliable like UDP - will start with a handshake involving only one or at most a few packets and waiting for a reply before sending more. Thus, as long as we can set up a connection quicker than the re-transmit timer in the host's network stack, buffering those packets should result in no packet loss. Typically, setting up a new connection takes at most 500ms which should be fast enough to not trigger any re-transmits. Resolves: #3246. |
||
|
Jamil
|
a7b8253766 |
chore(apple/xcode): Cache rust build more intelligently using build phase (#7488)
Xcode has decent support for skipping certain build phases when input files haven't changed. This only happens for build phases within a single target, and not for entire Target dependencies. Before, we defined `Connlib` as its own bonafide build target, and then added it as a target dependency for the network extension targets. This causes Xcode to always run our `build-rust.sh` script, which takes around 30s on my M1 even when `rust/` hasn't changed. Instead, we can remove the `Connlib` target, and add a "Run script" phase to the network extension targets themselves. By configuring the input file list, Xcode will skip this phase if `rust/**/*.rs`, `rust/**/*.toml` and `rust/Cargo.lock` haven't changed. This makes it **much** faster to iterate on Swift code -- Xcode is _very_ fast when building pure Swift (sometimes under < 1s). <img width="1016" alt="Screenshot 2024-12-11 at 6 10 45 PM" src="https://github.com/user-attachments/assets/29b5f073-3d58-4c07-9592-f9209033c966" /> |
||
|
Jamil
|
253e1a6972 |
fix(tauri): Bump nanoid re: CVE-2024-55565 (#7487)
Fixes https://github.com/firezone/firezone/security/dependabot/136 |
||
|
Jamil
|
d775487508 |
fix(tauri): Bump cross-spawn re: CVE-2024-21538 (#7486)
Fixes https://github.com/firezone/firezone/security/dependabot/129 |
||
|
dependabot[bot]
|
d0aef8f1d8 |
build(deps): Bump nanoid from 3.3.7 to 3.3.8 in /website in the npm_and_yarn group (#7485)
Bumps the npm_and_yarn group in /website with 1 update: [nanoid](https://github.com/ai/nanoid). Updates `nanoid` from 3.3.7 to 3.3.8 <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/ai/nanoid/blob/main/CHANGELOG.md">nanoid's changelog</a>.</em></p> <blockquote> <h2>3.3.8</h2> <ul> <li>Fixed a way to break Nano ID by passing non-integer size (by <a href="https://github.com/myndzi"><code>@myndzi</code></a>).</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
e507197480 |
docs(gateway): add changelog entry for #7479 (#7484)
The issue is now fixed and `git pull` from `github.com` as a resource now works as expected. |
||
|
dependabot[bot]
|
6de324af05 |
build(deps): Bump tokio from 1.41.1 to 1.42.0 in /rust (#7469)
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.41.1 to 1.42.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/tokio/releases">tokio's releases</a>.</em></p> <blockquote> <h2>Tokio v1.42.0</h2> <h1>1.42.0 (Dec 3rd, 2024)</h1> <h3>Added</h3> <ul> <li>io: add <code>AsyncFd::{try_io, try_io_mut}</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6967">#6967</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>io: avoid <code>ptr->ref->ptr</code> roundtrip in RegistrationSet (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6929">#6929</a>)</li> <li>runtime: do not defer <code>yield_now</code> inside <code>block_in_place</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6999">#6999</a>)</li> </ul> <h3>Changes</h3> <ul> <li>io: simplify io readiness logic (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6966">#6966</a>)</li> </ul> <h3>Documented</h3> <ul> <li>net: fix docs for <code>tokio::net::unix::{pid_t, gid_t, uid_t}</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6791">#6791</a>)</li> <li>time: fix a typo in <code>Instant</code> docs (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6982">#6982</a>)</li> </ul> <p><a href="https://redirect.github.com/tokio-rs/tokio/issues/6791">#6791</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6791">tokio-rs/tokio#6791</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6929">#6929</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6929">tokio-rs/tokio#6929</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6966">#6966</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6966">tokio-rs/tokio#6966</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6967">#6967</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6967">tokio-rs/tokio#6967</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6982">#6982</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6982">tokio-rs/tokio#6982</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6999">#6999</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6999">tokio-rs/tokio#6999</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
87c3e4dd86 |
fix(telemetry): disable for unofficial environments (#7482)
On the one hand, learning about in which edgecases our software fails is useful and thus having telemetry also active for self-hosted users is beneficial. On the other hand, we have neither control nor a contact to those self-hosted and whatever they are doing might spam our Sentry account with errors that we can't do anything about. To mitigate this, we disable telemetry for self-hosted users with the next release. Once we have more resources, we can consider enabling this again. |
||
|
Thomas Eizinger
|
a0efc4cfdc |
fix(connlib): don't fail NAT64 on invalid IPv4 DSCP value (#7479)
As per the RFC, the IPv6 traffic class should be 1-to-1 translated to the IPv4 DSCP value. However, it appears that not all values here are valid. In particular, when attempting to reach GitHub over IPv6, we receive an IPv6 packet that has a traffic class value of 72 which is out-of-range for the IPv4 DSCP value, resulting in the following error on the Gateway: ``` Failed to translate packet: NAT64 failed: Error '72' is too big to be a 'IPv4 DSCP (Differentiated Services Code Point)' (maximum allowed value is '63') ``` The bigger scope of this issue is that this causes the ICMP packets returned to the client to be dropped which means that `ssh` spawned by `git` doesn't learn that the IPv6 address assigned by Firezone is not actually routable. Related: #7476. |
||
|
Thomas Eizinger
|
9b8e4d1764 |
chore(telemetry): remove outdated comments (#7483)
We are no longer using `ArcSwap` here. |
||
|
Thomas Eizinger
|
7e38d3caee | chore(connlib): downgrade warning about failed flow (#7480) | ||
|
Thomas Eizinger
|
83464c6412 |
ci: allow unmaintained gtk crates (#7478)
Tauri still depends on GTK3 which is now officially unmaintained (https://github.com/rustsec/advisory-db/pull/2164). I've asked the Tauri team for a position on it (https://github.com/tauri-apps/tauri/issues/11942). In the meantime, we'll have to allow the use of these unmaintained crates to unblock CI. |
||
|
Thomas Eizinger
|
81f71cba62 |
fix(telemetry): use package@version notation for releases (#7466)
In order for Sentry to parse our releases as semver, they need to be in the form of `package@version` [0]. Without this, the feature of "Mark this issue as resolved in the _next_ version" doesn't work properly because Sentry compares the versions as to when it first saw them vs parsing the semver string itself. We test versions prior to releasing them, meaning Sentry learns about a 1.4.0 version before it is actually released. This causes false-positive "regressions" even though they are fixed in a later (as per semver) release. This create some redundancy with the different DSNs that we are already using. I think it would make sense to consider merging the two projects we have for the GUI client for example. That is really just one project that happens to run as two binaries. For all other projects, I think the separation still makes sense because we e.g. may add Sentry to the "host" applications of Android and MacOS/iOS as well. For those, we would reuse the DSN and thus funnel the issues into the same Sentry project. As per Sentry's docs, releases are organisation-wide and therefore need a package identifier to be grouped correctly. [0]: https://docs.sentry.io/platforms/javascript/configuration/releases/#bind-the-version |
||
|
Jamil
|
ac608d560a |
refactor(apple): Migrate firezone-id file to keychain (#7464)
Unlike the App extension which runs as the user, the system extension introduced in macOS client 1.4.0 runs as `root` and thus cannot read the App Group container directory for the GUI process. However, both processes can read and write to the shared Keychain, which is how we pass the token between the two processes already. This PR does two things: 1. Tries to read an existing `firezone-id` from the pre-1.4.0 App Group container upon app launch. This needs to be done from the GUI process. If found, it stores it in the Keychain. 1. Refactors the `firezone-id` to be stored in the Keychain instead of a plaintext file going forward. The Keychain API is also cleaned up and abstracted to be more ergonomic to use for both Token and Firezone ID storage purposes. |
||
|
Jamil
|
45bfe0f2a3 |
chore(infra): Deny connections from US-sanctioned countries with HTTP 403 (#7462)
Implementing the remainder of the legally required block. Will be applied on Dec 9th, as we notified customers. |
||
|
Jamil
|
0cdfd1fd4f |
fix(apple/macos): Install system extension on app launch (#7459)
- Installs the system extension on app launch instead of each time we start the tunnel, as [recommended by Apple](https://developer.apple.com/documentation/systemextensions/installing-system-extensions-and-drivers). This will typically happen when the app is installed for the first time, or upgraded / downgraded. - Changes the completion handler functionality for observing the system extension status to an observed property on the class. This allows us to update the MenuBar based on the status of the installation, preventing the user from attempting to sign in unless the system extension has been installed. ~~This PR exposes a new, subtle issue - since we don't reinstall the system extension on each startTunnel, the process stays running. This is expected. However, now the logging handle needs to be maintained across connlib sessions, similar to the Android tunnel lifetime.~~ Fixed in #7460 Expect one or two more PRs to handle further edge cases with improved UX as more testing with the release build and upgrade/downgrade workflows are attempted. |
||
|
Thomas Eizinger
|
ddce9312ea |
fix(android): apply new log-filter on repeated connect call (#7461)
Related: #7460. Resolves: #5634. |
||
|
Thomas Eizinger
|
6115f662cf |
fix(apple): only initialise global logger once (#7460)
From within the FFI code, we have no control over the lifecycle of the host application and `connect` may be called multiple times from within the same process. Therefore, we cannot rely on the global logger state to **not** be set when `connect` gets called. To fix this, we cache the handles for the file logger and a reload-handle for the log filter in a `static` variable. This allows us to apply the new log-filter of a repeated `connect` call to the existing logger, even if `connect` is called multiple times from the same process. |
||
|
Thomas Eizinger
|
90cf191a7c |
feat(linux): multi-threaded TUN device operations (#7449)
## Context At present, we only have a single thread that reads and writes to the TUN device on all platforms. On Linux, it is possible to open the file descriptor of a TUN device multiple times by setting the `IFF_MULTI_QUEUE` option using `ioctl`. Using multi-queue, we can then spawn multiple threads that concurrently read and write to the TUN device. This is critical for achieving a better throughput. ## Solution `IFF_MULTI_QUEUE` is a Linux-only thing and therefore only applies to headless-client, GUI-client on Linux and the Gateway (it may also be possible on Android, I haven't tried). As such, we need to first change our internal abstractions a bit to move the creation of the TUN thread to the `Tun` abstraction itself. For this, we change the interface of `Tun` to the following: - `poll_recv_many`: An API, inspired by tokio's `mpsc::Receiver` where multiple items in a channel can be batch-received. - `poll_send_ready`: Mimics the API of `Sink` to check whether more items can be written. - `send`: Mimics the API of `Sink` to actually send an item. With these APIs in place, we can implement various (performance) improvements for the different platforms. - On Linux, this allows us to spawn multiple threads to read and write from the TUN device and send all packets into the same channel. The `Io` component of `connlib` then uses `poll_recv_many` to read batches of up to 100 packets at once. This ties in well with #7210 because we can then use GSO to send the encrypted packets in single syscalls to the OS. - On Windows, we already have a dedicated recv thread because `WinTun`'s most-convenient API uses blocking IO. As such, we can now also tie into that by batch-receiving from this channel. - In addition to using multiple threads, this API now also uses correct readiness checks on Linux, Darwin and Android to uphold backpressure in case we cannot write to the TUN device. ## Configuration Local testing has shown that 2 threads give the best performance for a local `iperf3` run. I suspect this is because there is only so much traffic that a single application (i.e. `iperf3`) can generate. With more than 2 threads, the throughput actually drops drastically because `connlib`'s main thread is too busy with lock-contention and triggering `Waker`s for the TUN threads (which mostly idle around if there are 4+ of them). I've made it configurable on the Gateway though so we can experiment with this during concurrent speedtests etc. In addition, switching `connlib` to a single-threaded tokio runtime further increased the throughput. I suspect due to less task / context switching. ## Results Local testing with `iperf3` shows some very promising results. We now achieve a throughput of 2+ Gbit/s. ``` Connecting to host 172.20.0.110, port 5201 Reverse mode, remote host 172.20.0.110 is sending [ 5] local 100.80.159.34 port 57040 connected to 172.20.0.110 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 274 MBytes 2.30 Gbits/sec [ 5] 1.00-2.00 sec 279 MBytes 2.34 Gbits/sec [ 5] 2.00-3.00 sec 216 MBytes 1.82 Gbits/sec [ 5] 3.00-4.00 sec 224 MBytes 1.88 Gbits/sec [ 5] 4.00-5.00 sec 234 MBytes 1.96 Gbits/sec [ 5] 5.00-6.00 sec 238 MBytes 2.00 Gbits/sec [ 5] 6.00-7.00 sec 229 MBytes 1.92 Gbits/sec [ 5] 7.00-8.00 sec 222 MBytes 1.86 Gbits/sec [ 5] 8.00-9.00 sec 223 MBytes 1.87 Gbits/sec [ 5] 9.00-10.00 sec 217 MBytes 1.82 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 2.30 GBytes 1.98 Gbits/sec 22247 sender [ 5] 0.00-10.00 sec 2.30 GBytes 1.98 Gbits/sec receiver iperf Done. ``` This is a pretty solid improvement over what is in `main`: ``` Connecting to host 172.20.0.110, port 5201 [ 5] local 100.65.159.3 port 56970 connected to 172.20.0.110 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 90.4 MBytes 758 Mbits/sec 1800 106 KBytes [ 5] 1.00-2.00 sec 93.4 MBytes 783 Mbits/sec 1550 51.6 KBytes [ 5] 2.00-3.00 sec 92.6 MBytes 777 Mbits/sec 1350 76.8 KBytes [ 5] 3.00-4.00 sec 92.9 MBytes 779 Mbits/sec 1800 56.4 KBytes [ 5] 4.00-5.00 sec 93.4 MBytes 783 Mbits/sec 1650 69.6 KBytes [ 5] 5.00-6.00 sec 90.6 MBytes 760 Mbits/sec 1500 73.2 KBytes [ 5] 6.00-7.00 sec 87.6 MBytes 735 Mbits/sec 1400 76.8 KBytes [ 5] 7.00-8.00 sec 92.6 MBytes 777 Mbits/sec 1600 82.7 KBytes [ 5] 8.00-9.00 sec 91.1 MBytes 764 Mbits/sec 1500 70.8 KBytes [ 5] 9.00-10.00 sec 92.0 MBytes 771 Mbits/sec 1550 85.1 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 917 MBytes 769 Mbits/sec 15700 sender [ 5] 0.00-10.00 sec 916 MBytes 768 Mbits/sec receiver iperf Done. ``` |
||
|
Thomas Eizinger
|
2f2ad2cffe |
docs(changelog): remove enable attr (#7458)
Idiomatic React is to conditionally render the entire element instead of passing down an `enable` attribute. |
||
|
Thomas Eizinger
|
cf9573faa1 |
build(rust): bump quinn-udp (#7457)
Pulling in a couple of fixes that have since landed on `quinn-udp`'s `main` branch. |
||
|
dependabot[bot]
|
eb77000ac2 |
build(deps): Bump the google group in /terraform/environments/production with 2 updates (#7423)
Bumps the google group in /terraform/environments/production with 2 updates: [hashicorp/google](https://github.com/hashicorp/terraform-provider-google) and [hashicorp/google-beta](https://github.com/hashicorp/terraform-provider-google-beta). Updates `hashicorp/google` from 6.10.0 to 6.12.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/hashicorp/terraform-provider-google/releases">hashicorp/google's releases</a>.</em></p> <blockquote> <h2>v6.12.0</h2> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_access_context_manager_access_policy</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20295">#20295</a>)</li> <li><strong>New Resource:</strong> <code>google_dataproc_gdc_spark_application</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20242">#20242</a>)</li> <li><strong>New Resource:</strong> <code>google_managed_kafka_cluster</code> and <code>google_managed_kafka_topic</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20237">#20237</a>)</li> </ul> <p>IMPROVEMENTS:</p> <ul> <li>artifactregistry: added <code>common_repository</code> field to <code>google_artifact_registry_repository</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20305">#20305</a>)</li> <li>cloudrunv2: added <code>urls</code> output field to <code>google_cloud_run_v2_service</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20313">#20313</a>)</li> <li>compute: added <code>IDPF</code> as a possible value for the <code>network_interface.nic_type</code> field in <code>google_compute_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20250">#20250</a>)</li> <li>compute: added <code>IDPF</code> as a possible value for the <code>guest_os_features.type</code> field in <code>google_compute_image</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20250">#20250</a>)</li> <li>compute: added <code>replica_names</code> field to <code>sql_database_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20202">#20202</a>)</li> <li>filestore: added <code>performance_config</code> field to <code>google_filestore_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20218">#20218</a>)</li> <li>redis: added <code>persistence_config</code> to <code>google_redis_cluster</code>. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20212">#20212</a>)</li> <li>securesourcemanager: added <code>workforce_identity_federation_config</code> field to <code>google_secure_source_manager_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20290">#20290</a>)</li> <li>spanner: added <code>default_backup_schedule_type</code> field to <code>google_spanner_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20213">#20213</a>)</li> <li>sql: added <code>psc_auto_connections</code> fields to <code>google_sql_database_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20307">#20307</a>)</li> </ul> <p>BUG FIXES:</p> <ul> <li>accesscontextmanager: fixed permadiff in perimeter <code>google_access_context_manager_service_perimeter_ingress_policy</code> and <code>google_access_context_manager_service_perimeter_egress_policy</code> resources when there are duplicate resources in the rules (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20294">#20294</a>)</li> <li> <ul> <li>accesscontextmanager: fixed comparison of <code>identity_type</code> in <code>ingress_from</code> and <code>egress_from</code> when the <code>IDENTITY_TYPE_UNSPECIFIED</code> is set (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20221">#20221</a>)</li> </ul> </li> <li>compute: fixed permadiff on attempted <code>type</code> field updates in <code>google_computer_security_policy</code>, updating this field will now force recreation of the resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20316">#20316</a>)</li> <li>identityplatform: fixed perma-diff originating from the <code>sign_in.anonymous.enabled</code> field in <code>google_identity_platform_config</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20244">#20244</a>)</li> </ul> <h2>v6.11.2</h2> <p>BUG FIXES:</p> <ul> <li>vertexai: fixed issue with google_vertex_ai_endpoint where upgrading to 6.11.0 would delete all traffic splits that were set outside Terraform (which was previously a required step for all meaningful use of this resource). (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20350">#20350</a>)</li> </ul> <h2>v6.11.1</h2> <p>BUG FIXES:</p> <ul> <li>container: fixed diff on <code>google_container_cluster.user_managed_keys_config</code> field for resources that had not set it. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20314">#20314</a>)</li> <li>container: marked <code>google_container_cluster.user_managed_keys_config</code> as immutable because it can't be updated in place. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20314">#20314</a>)</li> </ul> <h2>v6.11.0</h2> <p>NOTES:</p> <ul> <li>compute: migrated <code>google_compute_firewall_policy_rule</code> from DCL engine to MMv1 engine. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20160">#20160</a>)</li> </ul> <p>BREAKING CHANGES:</p> <ul> <li>looker: made <code>oauth_config</code> a required field in <code>google_looker_instance</code>, as creating this resource without that field always triggers an API error (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20196">#20196</a>)</li> </ul> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_spanner_database</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20114">#20114</a>)</li> <li><strong>New Resource:</strong> <code>google_apigee_api</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20113">#20113</a>)</li> <li><strong>New Resource:</strong> <code>google_dataproc_gdc_application_environment</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20165">#20165</a>)</li> <li><strong>New Resource:</strong> <code>google_dataproc_gdc_service_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20147">#20147</a>)</li> <li><strong>New Resource:</strong> <code>google_memorystore_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20108">#20108</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/hashicorp/terraform-provider-google/blob/main/CHANGELOG.md">hashicorp/google's changelog</a>.</em></p> <blockquote> <h2>6.12.0 (November 18, 2024)</h2> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_access_context_manager_access_policy</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20295">#20295</a>)</li> <li><strong>New Resource:</strong> <code>google_dataproc_gdc_spark_application</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20242">#20242</a>)</li> <li><strong>New Resource:</strong> <code>google_managed_kafka_cluster</code> and <code>google_managed_kafka_topic</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20237">#20237</a>)</li> </ul> <p>IMPROVEMENTS:</p> <ul> <li>artifactregistry: added <code>common_repository</code> field to <code>google_artifact_registry_repository</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20305">#20305</a>)</li> <li>cloudrunv2: added <code>urls</code> output field to <code>google_cloud_run_v2_service</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20313">#20313</a>)</li> <li>compute: added <code>IDPF</code> as a possible value for the <code>network_interface.nic_type</code> field in <code>google_compute_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20250">#20250</a>)</li> <li>compute: added <code>IDPF</code> as a possible value for the <code>guest_os_features.type</code> field in <code>google_compute_image</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20250">#20250</a>)</li> <li>compute: added <code>replica_names</code> field to <code>sql_database_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20202">#20202</a>)</li> <li>filestore: added <code>performance_config</code> field to <code>google_filestore_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20218">#20218</a>)</li> <li>redis: added <code>persistence_config</code> to <code>google_redis_cluster</code>. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20212">#20212</a>)</li> <li>securesourcemanager: added <code>workforce_identity_federation_config</code> field to <code>google_secure_source_manager_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20290">#20290</a>)</li> <li>spanner: added <code>default_backup_schedule_type</code> field to <code>google_spanner_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20213">#20213</a>)</li> <li>sql: added <code>psc_auto_connections</code> fields to <code>google_sql_database_instance</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20307">#20307</a>)</li> </ul> <p>BUG FIXES:</p> <ul> <li>accesscontextmanager: fixed permadiff in perimeter <code>google_access_context_manager_service_perimeter_ingress_policy</code> and <code>google_access_context_manager_service_perimeter_egress_policy</code> resources when there are duplicate resources in the rules (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20294">#20294</a>)</li> <li> <ul> <li>accesscontextmanager: fixed comparison of <code>identity_type</code> in <code>ingress_from</code> and <code>egress_from</code> when the <code>IDENTITY_TYPE_UNSPECIFIED</code> is set (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20221">#20221</a>)</li> </ul> </li> <li>compute: fixed permadiff on attempted <code>type</code> field updates in <code>google_computer_security_policy</code>, updating this field will now force recreation of the resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20316">#20316</a>)</li> <li>identityplatform: fixed perma-diff originating from the <code>sign_in.anonymous.enabled</code> field in <code>google_identity_platform_config</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20244">#20244</a>)</li> </ul> <h2>6.11.2 (November 15, 2024)</h2> <p>BUG FIXES:</p> <ul> <li>vertexai: fixed issue with google_vertex_ai_endpoint where upgrading to 6.11.0 would delete all traffic splits that were set outside Terraform (which was previously a required step for all meaningful use of this resource). (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20350">#20350</a>)</li> </ul> <h2>6.11.1 (November 12, 2024)</h2> <p>BUG FIXES:</p> <ul> <li>container: fixed diff on <code>google_container_cluster.user_managed_keys_config</code> field for resources that had not set it. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20314">#20314</a>)</li> <li>container: marked <code>google_container_cluster.user_managed_keys_config</code> as immutable because it can't be updated in place. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20314">#20314</a>)</li> </ul> <h2>6.11.0 (November 11, 2024)</h2> <p>NOTES:</p> <ul> <li>compute: migrated <code>google_compute_firewall_policy_rule</code> from DCL engine to MMv1 engine. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20160">#20160</a>)</li> </ul> <p>BREAKING CHANGES:</p> <ul> <li>looker: made <code>oauth_config</code> a required field in <code>google_looker_instance</code>, as creating this resource without that field always triggers an API error (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20196">#20196</a>)</li> </ul> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_spanner_database</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20114">#20114</a>)</li> <li><strong>New Resource:</strong> <code>google_apigee_api</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20113">#20113</a>)</li> <li><strong>New Resource:</strong> <code>google_dataproc_gdc_application_environment</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20165">#20165</a>)</li> <li><strong>New Resource:</strong> <code>google_dataproc_gdc_service_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20147">#20147</a>)</li> <li><strong>New Resource:</strong> <code>google_memorystore_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20108">#20108</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
4094e231fd |
build(deps-dev): Bump tailwindcss from 3.4.14 to 3.4.16 in /rust/gui-client (#7456)
Bumps [tailwindcss](https://github.com/tailwindlabs/tailwindcss) from 3.4.14 to 3.4.16. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/releases">tailwindcss's releases</a>.</em></p> <blockquote> <h2>v3.4.16</h2> <h3>Fixed</h3> <ul> <li>Ensure the TypeScript types for <code>PluginsConfig</code> allow <code>undefined</code> values (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/14668">#14668</a>)</li> </ul> <h1>Changed</h1> <ul> <li>Bumped lilconfig to v3.x (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15289">#15289</a>)</li> </ul> <h2>v3.4.15</h2> <ul> <li>Bump versions for security vulnerabilities (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/14697">#14697</a>)</li> <li>Ensure the TypeScript types for the <code>boxShadow</code> theme configuration allows arrays (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/14856">#14856</a>)</li> <li>Set fallback for opacity variables to ensure setting colors with the <code>selection:*</code> variant works in Chrome 131 (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15003">#15003</a>)</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/blob/v3.4.16/CHANGELOG.md">tailwindcss's changelog</a>.</em></p> <blockquote> <h2>[3.4.16] - 2024-12-03</h2> <h3>Fixed</h3> <ul> <li>Ensure the TypeScript types for <code>PluginsConfig</code> allow <code>undefined</code> values (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/14668">#14668</a>)</li> </ul> <h1>Changed</h1> <ul> <li>Bumped lilconfig to v3.x (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15289">#15289</a>)</li> </ul> <h2>[3.4.15] - 2024-11-14</h2> <ul> <li>Bump versions for security vulnerabilities (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/14697">#14697</a>)</li> <li>Ensure the TypeScript types for the <code>boxShadow</code> theme configuration allows arrays (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/14856">#14856</a>)</li> <li>Set fallback for opacity variables to ensure setting colors with the <code>selection:*</code> variant works in Chrome 131 (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15003">#15003</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
0b30c2de73 |
build(deps): Bump bytes from 1.7.2 to 1.9.0 in /rust (#7448)
Bumps [bytes](https://github.com/tokio-rs/bytes) from 1.7.2 to 1.9.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/bytes/releases">bytes's releases</a>.</em></p> <blockquote> <h2>Bytes v1.9.0</h2> <h1>1.9.0 (November 27, 2024)</h1> <h3>Added</h3> <ul> <li>Add <code>Bytes::from_owner</code> to enable externally-allocated memory (<a href="https://redirect.github.com/tokio-rs/bytes/issues/742">#742</a>)</li> </ul> <h3>Documented</h3> <ul> <li>Fix typo in Buf::chunk() comment (<a href="https://redirect.github.com/tokio-rs/bytes/issues/744">#744</a>)</li> </ul> <h3>Internal changes</h3> <ul> <li>Replace BufMut::put with BufMut::put_slice in Writer impl (<a href="https://redirect.github.com/tokio-rs/bytes/issues/745">#745</a>)</li> <li>Rename hex_impl! to fmt_impl! and reuse it for fmt::Debug (<a href="https://redirect.github.com/tokio-rs/bytes/issues/743">#743</a>)</li> </ul> <h2>Bytes 1.8.0</h2> <h1>1.8.0 (October 21, 2024)</h1> <ul> <li>Guarantee address in <code>split_off</code>/<code>split_to</code> for empty slices (<a href="https://redirect.github.com/tokio-rs/bytes/issues/740">#740</a>)</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/bytes/blob/master/CHANGELOG.md">bytes's changelog</a>.</em></p> <blockquote> <h1>1.9.0 (November 27, 2024)</h1> <h3>Added</h3> <ul> <li>Add <code>Bytes::from_owner</code> to enable externally-allocated memory (<a href="https://redirect.github.com/tokio-rs/bytes/issues/742">#742</a>)</li> </ul> <h3>Documented</h3> <ul> <li>Fix typo in Buf::chunk() comment (<a href="https://redirect.github.com/tokio-rs/bytes/issues/744">#744</a>)</li> </ul> <h3>Internal changes</h3> <ul> <li>Replace BufMut::put with BufMut::put_slice in Writer impl (<a href="https://redirect.github.com/tokio-rs/bytes/issues/745">#745</a>)</li> <li>Rename hex_impl! to fmt_impl! and reuse it for fmt::Debug (<a href="https://redirect.github.com/tokio-rs/bytes/issues/743">#743</a>)</li> </ul> <h1>1.8.0 (October 21, 2024)</h1> <ul> <li>Guarantee address in <code>split_off</code>/<code>split_to</code> for empty slices (<a href="https://redirect.github.com/tokio-rs/bytes/issues/740">#740</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
df285c1049 |
build(deps-dev): Bump @tauri-apps/cli from 2.0.4 to 2.1.0 in /rust/gui-client (#7431)
Bumps [@tauri-apps/cli](https://github.com/tauri-apps/tauri) from 2.0.4 to 2.1.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tauri-apps/tauri/releases"><code>@tauri-apps/cli</code>'s releases</a>.</em></p> <blockquote> <h2><code>@tauri-apps/cli</code> v2.1.0</h2> <h2>[2.1.0]</h2> <h3>New Features</h3> <ul> <li><a href=" |
||
|
dependabot[bot]
|
fdcd63cba6 |
build(deps-dev): Bump typescript from 5.6.3 to 5.7.2 in /rust/gui-client (#7432)
Bumps [typescript](https://github.com/microsoft/TypeScript) from 5.6.3 to 5.7.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/microsoft/TypeScript/releases">typescript's releases</a>.</em></p> <blockquote> <h2>TypeScript 5.7</h2> <p>For release notes, check out the <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/">release announcement</a>.</p> <ul> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.7.0%22+is%3Aclosed+">fixed issues query for Typescript 5.7.0 (Beta)</a>.</li> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.7.1%22+is%3Aclosed+">fixed issues query for Typescript 5.7.1 (RC)</a>.</li> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.7.2%22+is%3Aclosed+">fixed issues query for Typescript 5.7.2 (Stable)</a>.</li> </ul> <p>Downloads are available on:</p> <ul> <li><a href="https://www.npmjs.com/package/typescript">npm</a></li> </ul> <h2>TypeScript 5.7 RC</h2> <p>For release notes, check out the <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-7-rc/">release announcement</a>.</p> <p>For the complete list of fixed issues, check out the</p> <ul> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.7.0%22+is%3Aclosed+">fixed issues query for Typescript 5.7.0 (Beta)</a>.</li> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.7.1%22+is%3Aclosed+">fixed issues query for Typescript 5.7.1 (RC)</a>.</li> </ul> <p>Downloads are available on:</p> <ul> <li><a href="https://www.npmjs.com/package/typescript">npm</a></li> </ul> <h2>TypeScript 5.7 Beta</h2> <p>For release notes, check out the <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-7-beta/">release announcement</a>.</p> <p>For the complete list of fixed issues, check out the</p> <ul> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.7.0%22+is%3Aclosed+">fixed issues query for Typescript 5.7.0 (Beta)</a>.</li> </ul> <p>Downloads are available on:</p> <ul> <li><a href="https://www.npmjs.com/package/typescript">npm</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
48bd0f9804 |
chore: bump client versions to 1.4.0 (#7092)
In order to release the new control protocol to users, we need to bump the versions of the clients to 1.4.0. The portal has a version gate to only select gateways with version >= 1.4.0 for clients >= 1.4.0. Thus, bumping these versions can only happen once testing has completed and the gateway has actually been released as 1.4.0. Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com> |
||
|
Jamil
|
4233fb9490 |
fix(apple/macos): Add app sandbox and entitlements to network extension (#7455)
Apple [requires](https://github.com/firezone/firezone/actions/runs/12161693820/job/33916881718) network extensions on macOS to be sandboxed. Given this requirement, we must explicitly allow both the `com.apple.security.network.client` and `com.apple.security.network.security` entitlements for making outbound network requests and for opening sockets respectively. |
||
|
Jamil
|
c22bd3c230 |
fix(deps): Bump hashbrown to fix RUSTSEC-2024-0402 (#7454)
Fixes https://rustsec.org/advisories/RUSTSEC-2024-0402 |
||
|
Thomas Eizinger
|
b802021cc4 |
feat(connlib): implement idempotent control protocol for client (#6942)
Building on top of the gateway PR (#6941), this PR transitions the clients to the new control protocol. Clients are **not** backwards-compatible with old gateways. As a result, a certain customer environment MUST have at least one gateway with the above PR running in order for clients to be able to establish connections. With this transition, Clients send explicit events to Gateways whenever they assign IPs to a DNS resource name. The actual assignment only happens once and the IPs then remain stable for the duration of the client session. When the Gateway receives such an event, it will perform a DNS resolution of the requested domain name and set up the NAT between the assigned proxy IPs and the IPs the domain actually resolves to. In order to support self-healing of any problems that happen during this process, the client will send an "Assigned IPs" event every time it receives a DNS query for a particular domain. This in turn will trigger another DNS resolution on the Gateway. Effectively, this means that DNS queries for DNS resources propagate to the Gateway, triggering a DNS resolution there. In case the domain resolves to the same set of IPs, no state is changed to ensure existing connections are not interrupted. With this new functionality in place, we can delete the old logic around detecting "expired" IPs. This is considered a bugfix as this logic isn't currently working as intended. It has been observed multiple times that the Gateway can loop on this behaviour and resolving the same domain over and over again. The only theoretical "incompatibility" here is that pre-1.4.0 clients won't have access to this functionality of triggering DNS refreshes on a Gateway 1.4.2+ Gateway. However, as soon as this PR merges, we expect all admins to have already upgraded to a 1.4.0+ Gateway anyway which already mandates clients to be on 1.4.0+. Resolves: #7391. Resolves: #6828. |
||
|
dependabot[bot]
|
fd8ca853a3 |
build(deps): Bump serde from 1.0.210 to 1.0.215 in /rust (#7447)
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.210 to 1.0.215. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/serde-rs/serde/releases">serde's releases</a>.</em></p> <blockquote> <h2>v1.0.215</h2> <ul> <li>Produce warning when multiple fields or variants have the same deserialization name (<a href="https://redirect.github.com/serde-rs/serde/issues/2855">#2855</a>, <a href="https://redirect.github.com/serde-rs/serde/issues/2856">#2856</a>, <a href="https://redirect.github.com/serde-rs/serde/issues/2857">#2857</a>)</li> </ul> <h2>v1.0.214</h2> <ul> <li>Implement IntoDeserializer for all Deserializers in serde::de::value module (<a href="https://redirect.github.com/serde-rs/serde/issues/2568">#2568</a>, thanks <a href="https://github.com/Mingun"><code>@Mingun</code></a>)</li> </ul> <h2>v1.0.213</h2> <ul> <li>Fix support for macro-generated <code>with</code> attributes inside a newtype struct (<a href="https://redirect.github.com/serde-rs/serde/issues/2847">#2847</a>)</li> </ul> <h2>v1.0.212</h2> <ul> <li>Fix hygiene of macro-generated local variable accesses in serde(with) wrappers (<a href="https://redirect.github.com/serde-rs/serde/issues/2845">#2845</a>)</li> </ul> <h2>v1.0.211</h2> <ul> <li>Improve error reporting about mismatched signature in <code>with</code> and <code>default</code> attributes (<a href="https://redirect.github.com/serde-rs/serde/issues/2558">#2558</a>, thanks <a href="https://github.com/Mingun"><code>@Mingun</code></a>)</li> <li>Show variant aliases in error message when variant deserialization fails (<a href="https://redirect.github.com/serde-rs/serde/issues/2566">#2566</a>, thanks <a href="https://github.com/Mingun"><code>@Mingun</code></a>)</li> <li>Improve binary size of untagged enum and internally tagged enum deserialization by about 12% (<a href="https://redirect.github.com/serde-rs/serde/issues/2821">#2821</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Jamil
|
bd3f912542 |
refactor(apple/macos): Use System Extension packaging mode for macOS Network Extension (#7344)
To allow macOS users to rollback, it would be helpful to distribute a standalone macOS app, similar to how we distribute the GUI client. The first step in this process is to refactor the macOS client to use a System Extension -based Network Extension rather than an App Extension based one. This offers us the flexibility to distribute the macOS client outside the Mac App Store in addition to via the store. For this PR I focused on making the minimal set of changes necessary to support this change. This PR intentionally doesn't update the CI pipeline to notarize and attach a standalone bundle that will run ad-hoc on other Macs. That will come in a subsequent PR. One thing to note about System Extensions is that they're slightly more finicky when it comes to getting the signing and packaging right. Thus, the README.md is updated to account for the gotchas involved in developing System Extensions locally. Related: #7071. |
||
|
Jamil
|
15e75f80ba |
fix(apple/ios): Expose IPHONEOS_DEPLOYMENT_TARGET to tell rustc our iOS version (#7453)
Fixes a similar issue as #7443 where we were deleting the `IPHONEOS_DEPLOYMENT_TARGET` variable in our Rust build script, which caused lots of warnings about building for a different OS than being linked against. |
||
|
Thomas Eizinger
|
dd6b52b236 | chore(rust): share edition key via workspace table (#7451) | ||
|
Thomas Eizinger
|
f81f8b2ed7 |
fix(gui-client): don't share log-directives via file system (#7445)
At present, the GUI client shares the current log-directives with the IPC service via the file system. Supposedly, this has been done to allow the IPC service to start back up with the same log filter as before. This behaviour appears to be buggy though as we are receiving a fair number of error reports where this file is not writable. Instead of relying on the file system to communicate, we send the current log-directives to the IPC service as soon as we start up. The IPC service then uses the file system as a cache that log string and re-apply it on the next startup. This way, no two programs need to read / write the same file. The IPC service runs with higher privileges, so this should resolve the permission errors we are seeing in Sentry. |
||
|
dependabot[bot]
|
2b65e5f14d |
build(deps): Bump @tauri-apps/api from 2.0.3 to 2.1.1 in /rust/gui-client (#7433)
Bumps [@tauri-apps/api](https://github.com/tauri-apps/tauri) from 2.0.3 to 2.1.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tauri-apps/tauri/releases"><code>@tauri-apps/api</code>'s releases</a>.</em></p> <blockquote> <h2><code>@tauri-apps/api</code> v2.1.1</h2> <!-- raw HTML omitted --> <pre><code>No known vulnerabilities found </code></pre> <!-- raw HTML omitted --> <h2>[2.1.1]</h2> <h3>Bug Fixes</h3> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
9073bddaef |
fix(gateway): translate ICMP destination unreachable errors (#7398)
## Context The Gateway implements a stateful NAT that translates the destination IP and source protocol of every packet that targets a DNS resource IP. This is necessary because the IPs for DNS resources are generated on the client without actually performing a DNS lookup, instead it always generates 4 IPv4 and 4 IPv6 addresses. On the Gateway, these IPs are then assigned in a round-robin fashion to the actual IPs that the domain resolves to, necessitating a NAT64/46 translation in case a domain only resolves to IPs of one family. A domain may resolve to a set of IPs but not all of these IPs may be routable. Whilst an arguably poor practise of the domain administrator, routing problems can occur for all kinds of reasons and are well handled on the wider Internet. When an IP packet cannot be routed further, the current routing node generates an ICMP error describing the routing failure and sends it back to the original sender. ICMP is a layer 4 protocol itself, same as TCP and UDP. As such, sending out a UDP packet may result in receiving an ICMP response. In order to allow the sender to learn, which packet failed to route, the ICMP error embeds parts of the original packet in its payload [0] [1]. The Gateway's NAT table uses parts of the layer 4 protocol as part of its key; the UDP and TCP source port and the ICMP echo request identifier (further referred to as "source protocol"). An ICMP error message doesn't have any of these, meaning the lookup in the NAT table currently fails and the ICMP error is silently dropped. A lot of software implements a happy-eyeballs approach and probs for IPv6 and IPv4 connectivity simulataneously. The absence of the ICMP errors confuses that algorithm as it detects the packet loss and starts retransmits instead of giving up. ## Solution Upon receiving an ICMP error on the Gateway, we now extract the partially embedded packet in the ICMP error payload. We use the destination IP and source protocol of _that_ packet for the lookup in the NAT table. This returns us the original (client-assigned) destination IP and source protocol. In order for the Gateway's NAT to be transparent, we need to patch the packet embedded in the ICMP error to use the original destination and source protocol. We also have to account for the fact that the original packet may have been translated with NAT64/46 and translate it back. Finally, we generate an ICMP error with the appropriate code and embed the patched packet in its payload. ## Test implementation To test that this works for all kind of combinations, we extend `tunnel_test` to sample a list of unreachable IPs from all IPs sampled for DNS resources. Upon receiving a packet for one of these IPs, the Gateway will send an ICMP error back instead of invoking its regular echo reply logic. On the client-side, upon receiving an ICMP error, we extract the originally failed packet from the body and treat it as a successful response. This may seem a bit hacky at first but is actually how operating systems would treat ICMP errors as well. For example, a `TcpSocket::connect` call (triggering a TCP SYN packet) may fail with an IO error if we receive an ICMP error packet. Thus, in a way, the original packet got answered, just not with what we expected. In addition, by treating these ICMP errors as responses to the original packet, we automatically perform other assertions on them, like ensuring that they come from the right IP address, that there are no unexpected packets etc. ## Test alternatives It is tricky to solve this in other ways in the test suite because at the time of generating a packet for a DNS resource, we don't know the actual IP that is being targeted by a certain proxy IP unless we'd start reimplementing the round-robin algorithm employed by the Gateway. To "test" the transparency of the NAT, we'd like to avoid knowing about these implementation details in the test. ## Future work In this PR, we currently only deal with "Destination Unreachable" ICMP errors. There are other ICMP messages such as ICMPv6's `PacketTooBig` or `ParameterProblem`. We should eventually handle these as well. They are being deferred because translating those between the different IP versions is only partially implemented and would thus require more work. The most pressing need is to translate destination unreachable errors to enable happy-eyeballs algorithms to work correctly. Resolves: #5614. Resolves: #6371. [0]: https://www.rfc-editor.org/rfc/rfc792 [1]: https://www.rfc-editor.org/rfc/rfc4443#section-3.1 |
||
|
Thomas Eizinger
|
4f92a0d7ca |
refactor(gui-client): tidy up GUI controller code (#7444)
This PR intends to be a pure refactoring, i.e. no behaviour change. It simplifies a few aspects of the GUI controller event-loop by getting rid of the `select!` macro. We also remove some indirection of the `gui_controller::Builder`. |
||
|
Thomas Eizinger
|
8bc1277c24 |
fix(telemetry): include span attributes in breadcrumbs (#7421)
This is another attempt at fixing #7386. Previous PR was #7379. The difference is, this time it works! In the following screenshot, `handle_input` is a currently active span.  I had to make some patches to Sentry, most notably: - https://github.com/getsentry/sentry-rust/pull/708 - https://github.com/getsentry/sentry-rust/pull/712 The way we configure Sentry is quite tricky: First and foremost, we need to understand that the `tracing` adapter for Sentry has a `span_filter` configuration. When a span gets filtered out there, the rest of `sentry-tracing` never sees the data in that span. Thus, in order to capture variables from spans, we need to have a fairly generous span filter. In this PR, we change this span filter to include all spans except those on TRACE level. Secondly, by default, the Sentry SDK doesn't send any spans to the backend, i.e. the sampling rate is 0. Previously, we set the sampling rate to 1.0 because the `span_filter` was already filtering out all non-telemetry spans. A telemetry span is a concept that we invented. It is a span that gets sampled at _creation_ time with a probability of 1%. This is useful because creating a lot of spans is also expensive, so we don't want to do it e.g. on a per-packet basis. With just these configuration options, we now have a problem: We don't want to submit all spans to Sentry but we need the `span_filter` to allow all spans otherwise we can't capture the contextual fields from the span in breadcrumbs. Luckily, the Sentry SDK has another configuration option: `traces_sampler`. The `traces_sampler` gets to compute a sampling rate for each individual span. This allows us to discard all spans from being sent to Sentry unless they are `telemetry` spans. Resolves: #7386. |