mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-28 02:18:50 +00:00
d6a1966a42e7aaaffc051ce4dfd2ee945ce7ea01
254 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Thomas Eizinger
|
b34af41eb0 |
feat(relay): remove standalone mode (#7701)
Previously, it was possible to use the Firezone relay in "standalone" mode where it would not attempt to connect to a portal. A long time ago, this mode was introduced in order for us to test the TURN compatibility of the relay with non-Firezone TURN clients. These tests have long been removed and thus the mode is no longer required. The positive side-effect of this is that we can make the `FIREZONE_API_URL` a mandatory parameter and thus direct self-hosted users towards setting this to the endpoint of their self-hosted portal. |
||
|
Thomas Eizinger
|
e499d3e856 |
feat(relay): make telemetry opt-in (#7697)
Currently, telemetry via Sentry in our relay code is opt-out but won't actually activate for a portal instance that isn't our staging or production environment. However, this isn't enough to prevent alerts from relay instances that aren't ours. It turns out that some self-hosted customers don't realise that they have to change the portal URL to their self-hosted portal. Without changing that, the relay will attempt to authenticate to our production portal with an unknown token and error out with a 401, logging a false-positive to Sentry. |
||
|
Thomas Eizinger
|
5b2d7f1adf | fix(relay): don't warn when running in standalone mode (#7573) | ||
|
Thomas Eizinger
|
7df4389fa6 |
refactor(relay): avoid stringifying error early (#7553)
When the portal connection in a relay fails, we currently stringify the error early. This is unnecessary and we should instead retain the full error chain for as long as possible. |
||
|
Thomas Eizinger
|
8e0f00a3a6 |
fix(relay): buffer packets in case IO is busy (#7536)
At present, the relay's event-loop simply drops a UDP packet in case the socket is not ready for writing. This is terrible for throughput because it means the encapsulated packet within the WG payload needs to be retransmitted by the source after a timeout. To avoid this, we instead buffer the packet and suspend the event loop until it has been correctly flushed out. This may still cause packet loss because the receive buffer may overflow in the meantime. However, there is nothing we can do about that because UDP itself doesn't have any backpressure. The relay listens on many sockets at once via a separate worker thread and an `mio` event-loop. In addition to the current subscription to readable event, we now also subscribe to writable events. At the very top of the relay's event-loop, we insert a `flush` function that ensures all buffered packets have been written out and - in case writing a packet fails - suspends the event-loop with a waker. If we receive a new event for write-readiness, we wake the waker which will trigger a new call to `Eventloop::poll` where we again try to flush the pending packet. We don't bother with tracking exactly, which socket sent the write-readiness and which socket we have still pending packets in. Instead, we suspend the entire event-loop until all pending packets have been flushed. Resolves: #7519. |
||
|
Thomas Eizinger
|
48857d3bc8 |
chore(relay): downgrade allocation mismatch warn on CHANNEL_BIND (#7505)
This code-path is handled gracefully in `connlib`, no need to issue a warning here. |
||
|
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
|
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
|
dd6b52b236 | chore(rust): share edition key via workspace table (#7451) | ||
|
Thomas Eizinger
|
d06bdaac91 |
chore(relay): don't warn on existing allocation (#7415)
A client may have lost its state and therefore "probe" the relay whether or not is still has an allocation. If it does, it will react to the error, delete it and make a new one. This is no reason to print a warning on the relay side. |
||
|
Thomas Eizinger
|
932f6791fb |
fix(phoenix-channel): lazily create backoff timer (#7414)
Our `phoenix-channel` component is responsible for maintaining a WebSocket connection to the portal. In case that connection fails, we want to reconnect to it using an exponential backoff, eventually giving up after a certain amount of time. Unfortunately, the code we have today doesn't quite do that. An `ExponentialBackoff` has a setting for the `max_elapsed_time`. Regardless of how many and how often we retry something, we won't ever wait longer than this amount of time. For the Relay, this is set to 15min. For other components its indefinite (Gateway, headless-client), or very long (30 days for Android, 1 day for Apple). The point in time from which this duration is counted is when the `ExponentialBackoff` is **constructed** which translates to when we **first** connected to the portal. As a result, our backoff would immediately fail on the first error if it has been longer than `max_elapsed_time` since we first connected. For most components, this codepath is not relevant because the `max_elapsed_time` is so long. For the Relay however, that is only 15 minutes so chances are, the Relay would immediately fail (and get rebooted) on the first connection error with the portal. To fix this, we now lazily create the `ExponentialBackoff` on the first error. This bug has some interesting consequences: When a relay reboots, it looses all its state, i.e. allocations, channel bindings, available nonces etc, stamp-secret. Thus, all credentials and state that got distributed to Clients and Gateways get invalidated, causing disconnects from the Relay. We have observed these alerts in Sentry for a while and couldn't explain them. Most likely, this is the root cause for those because whilst a Relay disconnects, the portal also cannot detect its presence and pro-actively inform Clients and Gateways to no longer use this Relay. |
||
|
Thomas Eizinger
|
bea8393248 |
fix(relay): reduce number of warnings (#7411)
With this PR, we reduce some of the warnings emitted by the relay. If we can only partially fulfill an allocation, we now only emit a warning. Similarly, if we receive a repeated SIGTERM signal, we shut down successfully (i.e. exit with code 0) instead of failing the event-loop. During normal operation, we wait for all allocations to expire before we shut down. On CI however, the relay gets shutdown much earlier so this would generate unnecessary errors. Receiving another SIGTERM is a user-initiated action so we shouldn't fail as a result but instead just comply with it. |
||
|
Thomas Eizinger
|
e91a076307 |
refactor(relay): improve error messages on failed requests (#7405)
Some house-keeping that should make debugging issues around relay-disconnects easier. |
||
|
Thomas Eizinger
|
973a806707 |
feat(relay): add Sentry crash reporting (#7406)
In addition to monitoring clients and gateways, it is also useful to monitor relays in the same way. This gives us alerts on ERROR and WARN messages logged by the relay as well as panics. |
||
|
Thomas Eizinger
|
2c26fc9c0e |
ci: lint Rust dependencies using cargo deny (#7390)
One of Rust's promises is "if it compiles, it works". However, there are certain situations in which this isn't true. In particular, when using dynamic typing patterns where trait objects are downcast to concrete types, having two versions of the same dependency can silently break things. This happened in #7379 where I forgot to patch a certain Sentry dependency. A similar problem exists with our `tracing-stackdriver` dependency (see #7241). Lastly, duplicate dependencies increase the compile-times of a project, so we should aim for having as few duplicate versions of a particular dependency as possible in our dependency graph. This PR introduces `cargo deny`, a linter for Rust dependencies. In addition to linting for duplicate dependencies, it also enforces that all dependencies are compatible with an allow-list of licenses and it warns when a dependency is referred to from multiple crates without introducing a workspace dependency. Thanks to existing tooling (https://github.com/mainmatter/cargo-autoinherit), transitioning all dependencies to workspace dependencies was quite easy. Resolves: #7241. |
||
|
Thomas Eizinger
|
44c1b453f7 |
chore(relay): document authentication scheme (#7388)
Follow-up from #7378 to answer some of the questions. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Thomas Eizinger
|
56db250e2c |
feat(connlib): validate integrity of all relay responses (#7378)
In order to avoid processing of responses of relays that somehow got altered on the network path, we now use the client's `password` as a shared secret for the relay to also authenticate its responses. This means that not all message can be authenticated. In particular, BINDING requests will still be unauthenticated. Performing this validation now requires every component that crafts input to the `Allocation` to include a valid `MessageIntegrity` attribute. This is somewhat problematic for the regression tests of the relay and the unit tests of `Allocation`. In both cases, we implement workarounds so we don't have to actually compute a valid `MessageIntegrity`. This is deemed acceptable because: - Both of these are just tests. - We do test the validation path using `tunnel_test` because there we run an actual relay. |
||
|
dependabot[bot]
|
4014373dc2 |
build(deps): Bump clap from 4.5.20 to 4.5.21 in /rust (#7369)
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.20 to 4.5.21. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/releases">clap's releases</a>.</em></p> <blockquote> <h2>v4.5.21</h2> <h2>[4.5.21] - 2024-11-13</h2> <h3>Fixes</h3> <ul> <li><em>(parser)</em> Ensure defaults are filled in on error with <code>ignore_errors(true)</code></li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's changelog</a>.</em></p> <blockquote> <h2>[4.5.21] - 2024-11-13</h2> <h3>Fixes</h3> <ul> <li><em>(parser)</em> Ensure defaults are filled in on error with <code>ignore_errors(true)</code></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
48ba2869a8 |
chore(rust): ban the use of .unwrap except in tests (#7319)
Using the clippy lint `unwrap_used`, we can automatically lint against all uses of `.unwrap()` on `Result` and `Option`. This turns up quite a few results actually. In most cases, they are invariants that can't actually be hit. For these, we change them to `Option`. In other cases, they can actually be hit. For example, if the user supplies an invalid log-filter. Activating this lint ensures the compiler will yell at us every time we use `.unwrap` to double-check whether we do indeed want to panic here. Resolves: #7292. |
||
|
dependabot[bot]
|
7e4e190cd6 |
build(deps): Bump test-strategy from 0.3.1 to 0.4.0 in /rust (#7308)
Bumps [test-strategy](https://github.com/frozenlib/test-strategy) from 0.3.1 to 0.4.0. <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
3a7101bac0 |
build(deps): Bump the otel group across 1 directory with 4 updates (#7031)
Bumps the otel group with 4 updates in the /rust directory: [opentelemetry](https://github.com/open-telemetry/opentelemetry-rust), [opentelemetry-otlp](https://github.com/open-telemetry/opentelemetry-rust), [opentelemetry_sdk](https://github.com/open-telemetry/opentelemetry-rust) and [tracing-opentelemetry](https://github.com/tokio-rs/tracing-opentelemetry). Updates `opentelemetry` from 0.24.0 to 0.26.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/open-telemetry/opentelemetry-rust/releases">opentelemetry's releases</a>.</em></p> <blockquote> <h2>0.26.0 Release</h2> <p>See changelog for individual crates to know the exact set of changes. As informed during previous release, all crates from this repo follows same version (0.26.0 for this release). This release also upgrades Metric API (part of <code>opentelemetry</code> crate) from alpha to beta.</p> <h2>OpenTelemetry 0.25.0 Release</h2> <p>See changelog for individual crates to know the exact set of changes. This release onwards, all crates from this repo follows same version (0.25.0 for today's release).</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
73eebd2c4d |
refactor(rust): consistently record errors as tracing::Value (#7104)
Our logging library, `tracing` supports structured logging. This is useful because it preserves the more than just the string representation of a value and thus allows the active logging backend(s) to capture more information for a particular value. In the case of errors, this is especially useful because it allows us to capture the sources of a particular error. Unfortunately, recording an error as a tracing value is a bit cumbersome because `tracing::Value` is only implemented for `&dyn std::error::Error`. Casting an error to this is quite verbose. To make it easier, we introduce two utility functions in `firezone-logging`: - `std_dyn_err` - `anyhow_dyn_err` Tracking errors as correct `tracing::Value`s will be especially helpful once we enable Sentry's `tracing` integration: https://docs.rs/sentry-tracing/latest/sentry_tracing/#tracking-errors |
||
|
Thomas Eizinger
|
2d4818e007 |
refactor(connlib): rotate tunnel private key on reset (#6909)
With the new control protocol specified in #6461, the client will no longer initiate new connections. Instead, the credentials are generated deterministically by the portal based on the gateway's and the client's public key. For as long as they use the same public key, they also have the same in-memory state which makes creating connections idempotent. What we didn't consider in the new design at first is that when clients roam, they discard all connections but keep the same private key. As a result, the portal would generate the same ICE credentials which means the gateway thinks it can reuse the existing connection when new flows get authorized. The client however discarded all connections (and rotated its ports and maybe IPs), meaning the previous candidates sent to the gateway are no longer valid and connectivity fails. We fix this by also rotating the private keys upon reset. Rotating the keys itself isn't enough, we also need to propagate the new public key all the way "over" to the phoenix channel component which lives separately from connlib's data plane. To achieve this, we change `PhoenixChannel` to now start in the "disconnected" state and require an explicit `connect` call. In addition, the `LoginUrl` constructed by various components now acts merely as a "prototype", which may require additional data to construct a fully valid URL. In the case of client and gateway, this is the public key of the `Node`. This additional parameter needs to be passed to `PhoenixChannel` in the `connect` call, thus forming a type-safe contract that ensures we never attempt to connect without providing a public key. For the relay, this doesn't apply. Lastly, this allows us to tidy up the code a bit by: a) generating the `Node`'s private key from the existing RNG b) removing `ConnectArgs` which only had two members left Related: #6461. Related: #6732. |
||
|
dependabot[bot]
|
1140656b83 |
build(deps): Bump clap from 4.5.18 to 4.5.19 in /rust (#6950)
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.18 to 4.5.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/releases">clap's releases</a>.</em></p> <blockquote> <h2>v4.5.19</h2> <h2>[4.5.19] - 2024-10-01</h2> <h3>Internal</h3> <ul> <li>Update dependencies</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's changelog</a>.</em></p> <blockquote> <h2>[4.5.19] - 2024-10-01</h2> <h3>Internal</h3> <ul> <li>Update dependencies</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
2e8cc2471a |
build(deps): Bump derive_more from 0.99.18 to 1.0.0 in /rust (#6870)
Bumps [derive_more](https://github.com/JelteF/derive_more) from 0.99.18 to 1.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/JelteF/derive_more/releases">derive_more's releases</a>.</em></p> <blockquote> <h2>v1.0.0 - Finally a stable release</h2> <p><code>derive_more</code> is a library that adds derives for many of the standard library traits. By using this library the following code just works:</p> <pre lang="rust"><code>use derive_more::{Add, Display, From, Into}; <p>#[derive(PartialEq, From, Add)] struct MyInt(i32);</p> <p>#[derive(PartialEq, From, Into)] struct Point2D { x: i32, y: i32, }</p> <p>#[derive(PartialEq, From, Add, Display)] enum MyEnum { #[display("int: {_0}")] Int(i32), Uint(u32), #[display("nothing")] Nothing, }</p> <p>assert!(MyInt(11) == MyInt(5) + 6.into()); assert!((5, 6) == Point2D { x: 5, y: 6 }.into()); assert!(MyEnum::Int(15) == (MyEnum::Int(8) + 7.into()).unwrap()); assert!(MyEnum::Int(15).to_string() == "int: 15"); assert!(MyEnum::Uint(42).to_string() == "42"); assert!(MyEnum::Nothing.to_string() == "nothing"); </code></pre></p> <p>Now, more than 8 years after the first commit and almost 5 years after the 0.99.0 release, <code>derive_more</code> has finally reached its 1.0.0 release. This release contains a lot of changes (including some breaking ones) to make it easier to use the derives and make it possible to extend them without having to break backwards compatibility again. There are five major changes that I would like to call out, but there are many more changes that are documented below:</p> <ol> <li>There is a new <code>Debug</code> derive that can be used to easily customize <code>Debug</code> formatting.</li> <li>A greatly improved <code>Display</code> derive, which allows you to do anything that <a href="https://github.com/dtolnay/thiserror"><code>thiserror</code></a> provides, but it works for any type not just errors. And by combining the <code>Display</code> derive with the <code>Error</code> and <code>From</code> derives, there shouldn't really be any need to use <code>thiserror</code> anymore (if you are missing a feature/behaviour from <code>thiserror</code> please report an issue).</li> <li>Traits that can return errors now return a type that implements <code>Error</code> when an error occurs instead of a <code>&'static str</code>.</li> <li>When using <code>use derive_more::SomeTrait</code> the actual trait is also imported not just the derive macro. This is especially useful for <code>Error</code> and <code>Display</code></li> <li>The docs are now rendered on docs.rs and are much better overall.</li> </ol> <h3>Breaking changes</h3> <ul> <li>The minimum supported Rust version (MSRV) is now Rust 1.75.</li> <li>Add the <code>std</code> feature which should be disabled in <code>no_std</code> environments.</li> <li>All Cargo features, except <code>std</code>, are now disabled by default. The <code>full</code> feature can be used to get the old behavior of supporting all possible derives.</li> <li>The <code>TryFrom</code>, <code>Add</code>, <code>Sub</code>, <code>BitAnd</code>, <code>BitOr</code>, <code>BitXor</code>, <code>Not</code> and <code>Neg</code> derives now return a dedicated error type instead of a <code>&'static str</code> on error.</li> <li>The <code>FromStr</code> derive now uses a dedicated <code>FromStrError</code> error type instead of generating unique one each time.</li> <li>The <code>Display</code> derive (and other <code>fmt</code>-like ones) now uses <code>#[display("...", (<expr>),*)]</code> syntax instead of <code>#[display(fmt = "...", ("<expr>"),*)]</code>, and <code>#[display(bound(<bound>))]</code> instead of <code>#[display(bound = "<bound>")]</code>. So without the double quotes around the expressions and bounds.</li> <li>The <code>Debug</code> and <code>Display</code> derives (and other <code>fmt</code>-like ones) now transparently delegate to the inner type when <code>#[display("...", (<expr>),*)]</code> attribute is trivially substitutable with a transparent call. (<a href="https://redirect.github.com/JelteF/derive_more/pull/322">#322</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/JelteF/derive_more/blob/master/CHANGELOG.md">derive_more's changelog</a>.</em></p> <blockquote> <h2>1.0.0 - 2024-08-07</h2> <p>More than 8 years after the first commit and almost 5 years after the 0.99.0 release, <code>derive_more</code> has finally reached its 1.0.0 release. This release contains a lot of changes (including some breaking ones) to make it easier to use the derives and make it possible to extend them without having to break backwards compatibility again. There are five major changes that I would like to call out, but there are many more changes that are documented below:</p> <ol> <li>There is a new <code>Debug</code> derive that can be used to easily customize <code>Debug</code> formatting.</li> <li>A greatly improved <code>Display</code> derive, which allows you to do anything that <a href="https://github.com/dtolnay/thiserror"><code>thiserror</code></a> provides, but it works for any type not just errors. And by combining the <code>Display</code> derive with the <code>Error</code> and <code>From</code> derives, there shouldn't really be any need to use <code>thiserror</code> anymore (if you are missing a feature/behaviour from <code>thiserror</code> please report an issue).</li> <li>Traits that can return errors now return a type that implements <code>Error</code> when an error occurs instead of a <code>&'static str</code>.</li> <li>When using <code>use derive_more::SomeTrait</code> the actual trait is also imported not just the derive macro. This is especially useful for <code>Error</code> and <code>Display</code></li> <li>The docs are now rendered on docs.rs and are much better overall.</li> </ol> <h3>Breaking changes</h3> <ul> <li>The minimum supported Rust version (MSRV) is now Rust 1.75.</li> <li>Add the <code>std</code> feature which should be disabled in <code>no_std</code> environments.</li> <li>All Cargo features, except <code>std</code>, are now disabled by default. The <code>full</code> feature can be used to get the old behavior of supporting all possible derives.</li> <li>The <code>TryFrom</code>, <code>Add</code>, <code>Sub</code>, <code>BitAnd</code>, <code>BitOr</code>, <code>BitXor</code>, <code>Not</code> and <code>Neg</code> derives now return a dedicated error type instead of a <code>&'static str</code> on error.</li> <li>The <code>FromStr</code> derive now uses a dedicated <code>FromStrError</code> error type instead of generating unique one each time.</li> <li>The <code>Display</code> derive (and other <code>fmt</code>-like ones) now uses <code>#[display("...", (<expr>),*)]</code> syntax instead of <code>#[display(fmt = "...", ("<expr>"),*)]</code>, and <code>#[display(bound(<bound>))]</code> instead of <code>#[display(bound = "<bound>")]</code>. So without the double quotes around the expressions and bounds.</li> <li>The <code>Debug</code> and <code>Display</code> derives (and other <code>fmt</code>-like ones) now transparently delegate to the inner type when <code>#[display("...", (<expr>),*)]</code> attribute is trivially substitutable with a transparent call. (<a href="https://redirect.github.com/JelteF/derive_more/pull/322">#322</a>)</li> <li>The <code>DebugCustom</code> derive is renamed to just <code>Debug</code> (gated now under a separate <code>debug</code> feature), and its semantics were changed to be a superset of <code>std</code> variant of <code>Debug</code>.</li> <li>The <code>From</code> derive doesn't derive <code>From<()></code> for enum variants without any fields anymore. This feature was removed because it was considered useless in</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
fec6cc9923 |
build(deps): Bump clap from 4.5.4 to 4.5.13 in /rust (#6800)
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.4 to 4.5.13. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/releases">clap's releases</a>.</em></p> <blockquote> <h2>v4.5.13</h2> <h2>[4.5.13] - 2024-07-31</h2> <h3>Fixes</h3> <ul> <li><em>(derive)</em> Improve error message when <code>#[flatten]</code>ing an optional <code>#[group(skip)]</code></li> <li><em>(help)</em> Properly wrap long subcommand descriptions in help</li> </ul> <h2>v4.5.12</h2> <h2>[4.5.12] - 2024-07-31</h2> <h2>v4.5.10</h2> <h2>[4.5.10] - 2024-07-23</h2> <h2>v4.5.9</h2> <h2>[4.5.9] - 2024-07-09</h2> <h3>Fixes</h3> <ul> <li><em>(error)</em> When defining a custom help flag, be sure to suggest it like we do the built-in one</li> </ul> <h2>v4.5.8</h2> <h2>[4.5.8] - 2024-06-28</h2> <h3>Fixes</h3> <ul> <li>Reduce extra flushes</li> </ul> <h2>v4.5.7</h2> <h2>[4.5.7] - 2024-06-10</h2> <h3>Fixes</h3> <ul> <li>Clean up error message when too few arguments for <code>num_args</code></li> </ul> <h2>v4.5.6</h2> <h2>[4.5.6] - 2024-06-06</h2> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's changelog</a>.</em></p> <blockquote> <h2>[4.5.13] - 2024-07-31</h2> <h3>Fixes</h3> <ul> <li><em>(derive)</em> Improve error message when <code>#[flatten]</code>ing an optional <code>#[group(skip)]</code></li> <li><em>(help)</em> Properly wrap long subcommand descriptions in help</li> </ul> <h2>[4.5.12] - 2024-07-31</h2> <h2>[4.5.11] - 2024-07-25</h2> <h2>[4.5.10] - 2024-07-23</h2> <h2>[4.5.9] - 2024-07-09</h2> <h3>Fixes</h3> <ul> <li><em>(error)</em> When defining a custom help flag, be sure to suggest it like we do the built-in one</li> </ul> <h2>[4.5.8] - 2024-06-28</h2> <h3>Fixes</h3> <ul> <li>Reduce extra flushes</li> </ul> <h2>[4.5.7] - 2024-06-10</h2> <h3>Fixes</h3> <ul> <li>Clean up error message when too few arguments for <code>num_args</code></li> </ul> <h2>[4.5.6] - 2024-06-06</h2> <h2>[4.5.5] - 2024-06-06</h2> <h3>Fixes</h3> <ul> <li>Allow <code>exclusive</code> to override <code>required_unless_present</code>, <code>required_unless_present_any</code>, <code>required_unless_present_all</code></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
9378c8b0ac |
build(deps): Bump serde from 1.0.209 to 1.0.210 in /rust (#6642)
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.209 to 1.0.210. <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.210</h2> <ul> <li>Support serializing and deserializing <code>IpAddr</code> and <code>SocketAddr</code> in no-std mode on Rust 1.77+ (<a href="https://redirect.github.com/serde-rs/serde/issues/2816">#2816</a>, thanks <a href="https://github.com/MathiasKoch"><code>@MathiasKoch</code></a>)</li> <li>Make <code>serde::ser::StdError</code> and <code>serde::de::StdError</code> equivalent to <code>core::error::Error</code> on Rust 1.81+ (<a href="https://redirect.github.com/serde-rs/serde/issues/2818">#2818</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
fe952e634a |
build(deps): Bump serde from 1.0.204 to 1.0.209 in /rust (#6440)
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.204 to 1.0.209. <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.209</h2> <ul> <li>Fix deserialization of empty structs and empty tuples inside of untagged enums (<a href="https://redirect.github.com/serde-rs/serde/issues/2805">#2805</a>, thanks <a href="https://github.com/Mingun"><code>@Mingun</code></a>)</li> </ul> <h2>v1.0.208</h2> <ul> <li>Support serializing and deserializing unit structs in a <code>flatten</code> field (<a href="https://redirect.github.com/serde-rs/serde/issues/2802">#2802</a>, thanks <a href="https://github.com/jonhoo"><code>@jonhoo</code></a>)</li> </ul> <h2>v1.0.207</h2> <ul> <li>Improve interactions between <code>flatten</code> attribute and <code>skip_serializing</code>/<code>skip_deserializing</code> (<a href="https://redirect.github.com/serde-rs/serde/issues/2795">#2795</a>, thanks <a href="https://github.com/Mingun"><code>@Mingun</code></a>)</li> </ul> <h2>v1.0.206</h2> <ul> <li>Improve support for <code>flatten</code> attribute inside of enums (<a href="https://redirect.github.com/serde-rs/serde/issues/2567">#2567</a>, thanks <a href="https://github.com/Mingun"><code>@Mingun</code></a>)</li> </ul> <h2>v1.0.205</h2> <ul> <li>Use serialize_entry instead of serialize_key + serialize_value when serialize flattened newtype enum variants (<a href="https://redirect.github.com/serde-rs/serde/issues/2785">#2785</a>, thanks <a href="https://github.com/Mingun"><code>@Mingun</code></a>)</li> <li>Avoid triggering a collection_is_never_read lint in the deserialization of enums containing flattened fields (<a href="https://redirect.github.com/serde-rs/serde/issues/2791">#2791</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
896fe49f1f |
fix(relay): set better OTEL metadata (#6322)
Previously, the `service.name` attribute got overridden with "unknown service" from the detector used in `Resource::default`. To avoid this, we are now manually composing the two other detectors. This gives us a useful set of default labels from within the code yet it allows overriding all of them using `OTEL_RESOURCE_ATTRIBUTES`. |
||
|
Thomas Eizinger
|
3b56664e02 |
test(rust): ensure deterministic proptests (#6319)
For quite a while now, we have been making extensive use of property-based testing to ensure `connlib` works as intended. The idea of proptests is that - given a certain seed - we deterministically sample test inputs and assert properties on a given function. If the test fails, `proptest` prints the seed which can then be added to a regressions file to iterate on the test case and fix it. It is quite obvious that non-determinism in how the test input gets generated is no bueno and reduces the value we get out of these tests a fair bit. The `HashMap` and `HashSet` data structures are known to be non-deterministic in their iteration order. This causes non-determinism during the input generation because we make use of a lot of maps and sets to gradually build up the test input. We fix all uses of `HashMap` and `HashSet` by replacing them with `BTreeMap` and `BTreeSet`. To ensure this doesn't regress, we refactor `tunnel_test` to not make use of proptest's macros and instead, we initialise and run the test ourselves. This allows us to dump the sampled state and transitions into a file per test run. In CI, we then run a 2nd iteration of all regression tests and compare the sampled state and transitions with the previous run. They must match byte-for-byte. Finally, to discourage use of non-deterministic iteration, we ban the use of the iteration functions on `HashMap` and `HashSet` across the codebase. This doesn't catch iteration in a `for`-loop but it is better than not linting against it at all. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com> |
||
|
Thomas Eizinger
|
4750d76fce |
fix(relay): re-insert channel into fast-path map (#6332)
This is a test-failure detected in https://github.com/firezone/firezone/actions/runs/10426492110/job/28879531621. In the relay, we have fast-path lookup maps to for incoming traffic from peers. This improves throughput as any incoming packet only needs to look-up a single routing entry. Unfortunately, this creates duplication in how the data must be stored. In #6276, we correctly identified that channels must be re-bound on the relay when a client sends `CHANNEL_BIND` message whilst the channel is cooling down. What we failed to identify (and what as now caught by the tests) is that we also need to re-insert the entry into the fast-path lookup map to actually allow data from flowing through the channel. |
||
|
Thomas Eizinger
|
d399e65246 |
build(deps): bump tokio-tungstenite to 0.23 (#5509)
With the upgrade to 0.23, `tokio-tungstenite` pulls in `rustls` 0.27 which supports multiple crypto providers. By default, this uses the `aws-lc-crypto` provider. The previous default was `ring`. This PR bumps the necessary versions and installs the `ring` crypto provider at the beginning of each application, before connlib starts. We try and do this as early as possible to make it obvious that it only needs to happen once per process. Resolves: #5380. |
||
|
Thomas Eizinger
|
272e4b2bcd |
feat(snownet,relay): include sticky session ID in STUN requests (#6278)
For most cases, TURN identifies clients by their 3-tuple. This can make it hard to correlate logs in case the client roams or its NAT session gets reset, both of which cause the port to change. To make problem analysis easier, we include the RFC-recommended `SOFTWARE` attribute in all STUN requests created by `snownet`. Typically, this includes a textual description of who sent the request and a version number. See [0] for details. We don't track the version of `snownet` individually and passing the actual client-version across this many layers is deemed too complicated for now. What we can add though is a parameter that includes a sticky session ID. This session ID is computed based on the `Node`'s public key, meaning it doesn't change until the user logs-out and in again. On the relay, we now look for a `SOFTWARE` attribute in all STUN requests and optionally include it in all spans if it is present. [0]: https://datatracker.ietf.org/doc/html/rfc5389#section-15.10 |
||
|
dependabot[bot]
|
242ad55fc0 |
build(deps): Bump bytes from 1.6.0 to 1.7.1 in /rust (#6262)
Bumps [bytes](https://github.com/tokio-rs/bytes) from 1.6.0 to 1.7.1. <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 1.7.1</h2> <h1>1.7.1 (August 1, 2024)</h1> <p>This release reverts the following change due to a regression:</p> <ul> <li>Reuse capacity when possible in <code><BytesMut as Buf>::advance</code> impl (<a href="https://redirect.github.com/tokio-rs/bytes/issues/698">#698</a>)</li> </ul> <p>The revert can be found at <a href="https://redirect.github.com/tokio-rs/bytes/issues/726">#726</a>.</p> <h2>Bytes 1.7.0</h2> <h1>1.7.0 (July 31, 2024)</h1> <h3>Added</h3> <ul> <li>Add conversion from <code>Bytes</code> to <code>BytesMut</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/695">#695</a>, <a href="https://redirect.github.com/tokio-rs/bytes/issues/710">#710</a>)</li> <li>Add reclaim method without additional allocation (<a href="https://redirect.github.com/tokio-rs/bytes/issues/686">#686</a>)</li> </ul> <h3>Documented</h3> <ul> <li>Clarify how <code>BytesMut::zeroed</code> works (<a href="https://redirect.github.com/tokio-rs/bytes/issues/714">#714</a>)</li> <li>Clarify the behavior of <code>Buf::chunk</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/717">#717</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Change length condition of <code>BytesMut::truncate</code></li> <li>Reuse capacity when possible in <code><BytesMut as Buf>::advance</code> impl (<a href="https://redirect.github.com/tokio-rs/bytes/issues/698">#698</a>)</li> <li>Improve <code>must_use</code> suggestion of <code>BytesMut::split</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/699">#699</a>)</li> </ul> <h3>Internal changes</h3> <ul> <li>Use <code>ManuallyDrop</code> instead of <code>mem::forget</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/678">#678</a>)</li> <li>Don't set <code>len</code> in <code>BytesMut::reserve</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/682">#682</a>)</li> <li>Optimize <code>Bytes::copy_to_bytes</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/688">#688</a>)</li> <li>Refactor <code>BytesMut::truncate</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/694">#694</a>)</li> <li>Refactor <code>BytesMut::resize</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/696">#696</a>)</li> <li>Reorder assertion in <code>Bytes::split_to</code>, <code>Bytes::split_off</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/689">#689</a>, <a href="https://redirect.github.com/tokio-rs/bytes/issues/693">#693</a>)</li> <li>Use <code>offset_from</code> in more places (<a href="https://redirect.github.com/tokio-rs/bytes/issues/705">#705</a>)</li> <li>Correct the wrong usage of <code>IntoIter</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/707">#707</a>)</li> </ul> <h2>Bytes 1.6.1</h2> <p>This release fixes a bug where <code>Bytes::is_unique</code> returns incorrect values when the <code>Bytes</code> originates from a shared <code>BytesMut</code>. (<a href="https://redirect.github.com/tokio-rs/bytes/issues/718">#718</a>)</p> </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.7.1 (August 1, 2024)</h1> <p>This release reverts the following change due to a regression:</p> <ul> <li>Reuse capacity when possible in <code><BytesMut as Buf>::advance</code> impl (<a href="https://redirect.github.com/tokio-rs/bytes/issues/698">#698</a>)</li> </ul> <p>The revert can be found at <a href="https://redirect.github.com/tokio-rs/bytes/issues/726">#726</a>.</p> <h1>1.7.0 (July 31, 2024)</h1> <h3>Added</h3> <ul> <li>Add conversion from <code>Bytes</code> to <code>BytesMut</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/695">#695</a>, <a href="https://redirect.github.com/tokio-rs/bytes/issues/710">#710</a>)</li> <li>Add reclaim method without additional allocation (<a href="https://redirect.github.com/tokio-rs/bytes/issues/686">#686</a>)</li> </ul> <h3>Documented</h3> <ul> <li>Clarify how <code>BytesMut::zeroed</code> works (<a href="https://redirect.github.com/tokio-rs/bytes/issues/714">#714</a>)</li> <li>Clarify the behavior of <code>Buf::chunk</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/717">#717</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Change length condition of <code>BytesMut::truncate</code></li> <li>Reuse capacity when possible in <code><BytesMut as Buf>::advance</code> impl (<a href="https://redirect.github.com/tokio-rs/bytes/issues/698">#698</a>)</li> <li>Improve <code>must_use</code> suggestion of <code>BytesMut::split</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/699">#699</a>)</li> </ul> <h3>Internal changes</h3> <ul> <li>Use <code>ManuallyDrop</code> instead of <code>mem::forget</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/678">#678</a>)</li> <li>Don't set <code>len</code> in <code>BytesMut::reserve</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/682">#682</a>)</li> <li>Optimize <code>Bytes::copy_to_bytes</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/688">#688</a>)</li> <li>Refactor <code>BytesMut::truncate</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/694">#694</a>)</li> <li>Refactor <code>BytesMut::resize</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/696">#696</a>)</li> <li>Reorder assertion in <code>Bytes::split_to</code>, <code>Bytes::split_off</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/689">#689</a>, <a href="https://redirect.github.com/tokio-rs/bytes/issues/693">#693</a>)</li> <li>Use <code>offset_from</code> in more places (<a href="https://redirect.github.com/tokio-rs/bytes/issues/705">#705</a>)</li> <li>Correct the wrong usage of <code>IntoIter</code> (<a href="https://redirect.github.com/tokio-rs/bytes/issues/707">#707</a>)</li> </ul> <h1>1.6.1 (July 13, 2024)</h1> <p>This release fixes a bug where <code>Bytes::is_unique</code> returns incorrect values when the <code>Bytes</code> originates from a shared <code>BytesMut</code>. (<a href="https://redirect.github.com/tokio-rs/bytes/issues/718">#718</a>)</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
55c97acfc3 |
feat(relay): record error code as label in response counter metric (#6274)
This will allow us to write queries and thus alerts for increased number of error responses such as `Allocation Mismatch`. When attaching labels to metrics, it is important to avoid cardinality explosions. Thus, the possible label values should always be a fixed, bounded set of values. The possible error codes could be quite a few but in practise, we only use a handful and clients cannot influence, which error codes we send. Thus, it is safe to create labels for these codes. The same would not be true for IP addresses or ports for example. |
||
|
Thomas Eizinger
|
6e86a4dcba |
fix(snownet,relay): re-use channels to peers in cooldown period (#6276)
For efficiency reasons, TURN's data channels don't have any authentication or integrity metadata. Instead, the operate using a short 2-byte channel number to identify the target peer of the data. To avoid abuse, channel bindings are at most valid for 10 minutes before they need to be refreshed. In case they expire, there is a 5 minute cooldown period, before the same channel number can be bound to a different peer and before the same peer can be bound to a different channel. We had a similar issue in the past (#5613) where channels got rebound early. Whilst that was fixed and is no longer happening, a case that we didn't consider is what happens if we want to bind a channel to a peer that still has a channel bound but is currently cooling down (i.e. in the 5 minute period after its expiry). In that case, `snownet` would wrongly assume that there is no channel to this peer and try to bind a new one. That would get rejected by the relay with a bad request. To fix this, we simply need to check whether we still have a channel to this peer and if yes, return the same channel number. On the relay, we need to ensure that we consider a channel as `bound` again when it is being refreshed. We ensure that this doesn't regress in two ways: - We add a unit-test for the `ChannelBindings` struct - We modify the `Idle` transition to idle for 6 instead of 5 minutes. This ensures that a combination of 2 idle transitions puts the channel bindings into the 10-15 minute time window where rebinding the peer to a different channel fails. Related: #6265. |
||
|
Thomas Eizinger
|
0abbf6bba9 |
refactor(rust): inline http-health-check crate into bin-shared (#6258)
Now that we have the `bin-shared` crate, it is easy to move the health-check functionality into there. That allows us to get rid of a crate which makes navigating the workspace a bit easier. |
||
|
Thomas Eizinger
|
93d678aaea |
feat(relay): set OTEL metadata for metrics and traces (#6249)
I recently discovered that the metrics reporting to Google Cloud Metrics for the relays is actually working. Unfortunately, they are all bucketed together because we don't set the metadata correctly. This PR aims to fix that be setting some useful default metadata for traces and metrics and additionally, discoveres instance ID and name from GCE metadata. Related: #2033. |
||
|
Thomas Eizinger
|
bed625a312 |
chore(rust): make logging more ergonomic (#6237)
Setting up a logger is something that pretty much every entrypoint needs to do, be it a test, a shared library embedded in another app or a standalone application. Thus, it makes sense to introduce a dedicated crate that allows us to bundle all the things together, how we want to do logging. This allows us to introduce convenience functions like `firezone_logging::test` which allow you to construct a logger for a test as a one-liner. Crucially though, introducing `firezone-logging` gives us a place to store a default log directive that silences very noisy crates. When looking into a problem, it is common to start by simply setting the log-filter to `debug`. Without further action, this floods the output with logs from crates like `netlink_proto` on Linux. It is very unlikely that those are the logs that you want to see. Without a preset filter, the only alternative here is to explicitly turn off the log filter for `netlink_proto` by typing something like `RUST_LOG=netlink_proto=off,debug`. Especially when debugging issues with customers, this is annoying. Log filters can be overridden, i.e. a 2nd filter that matches the exact same scope overrides a previous one. Thus, with this design it is still possible to activate certain logs at runtime, even if they have silenced by default. I'd expect `firezone-logging` to attract more functionality in the future. For example, we want to support re-loading of log-filters on other platforms. Additionally, where logs get stored could also be defined in this crate. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com> |
||
|
dependabot[bot]
|
8352255499 |
build(deps): Bump serde from 1.0.203 to 1.0.204 in /rust (#6173)
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.203 to 1.0.204. <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.204</h2> <ul> <li>Apply #[diagnostic::on_unimplemented] attribute on Rust 1.78+ to suggest adding serde derive or enabling a "serde" feature flag in dependencies (<a href="https://redirect.github.com/serde-rs/serde/issues/2767">#2767</a>, thanks <a href="https://github.com/weiznich"><code>@weiznich</code></a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
bd49298240 |
build(deps): Bump tokio from 1.38.0 to 1.39.2 in /rust (#6082)
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.38.0 to 1.39.2. <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.39.2</h2> <h1>1.39.2 (July 27th, 2024)</h1> <p>This release fixes a regression where the <code>select!</code> macro stopped accepting expressions that make use of temporary lifetime extension. (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6722">#6722</a>)</p> <p><a href="https://redirect.github.com/tokio-rs/tokio/issues/6722">#6722</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6722">tokio-rs/tokio#6722</a></p> <h2>Tokio v1.39.1</h2> <h1>1.39.1 (July 23rd, 2024)</h1> <p>This release reverts "time: avoid traversing entries in the time wheel twice" because it contains a bug. (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6715">#6715</a>)</p> <p><a href="https://redirect.github.com/tokio-rs/tokio/issues/6715">#6715</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6715">tokio-rs/tokio#6715</a></p> <h2>Tokio v1.39.0</h2> <h1>1.39.0 (July 23rd, 2024)</h1> <ul> <li>This release bumps the MSRV to 1.70. (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6645">#6645</a>)</li> <li>This release upgrades to mio v1. (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6635">#6635</a>)</li> <li>This release upgrades to windows-sys v0.52 (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6154">#6154</a>)</li> </ul> <h3>Added</h3> <ul> <li>io: implement <code>AsyncSeek</code> for <code>Empty</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6663">#6663</a>)</li> <li>metrics: stabilize <code>num_alive_tasks</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6619">#6619</a>, <a href="https://redirect.github.com/tokio-rs/tokio/issues/6667">#6667</a>)</li> <li>process: add <code>Command::as_std_mut</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6608">#6608</a>)</li> <li>sync: add <code>watch::Sender::same_channel</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6637">#6637</a>)</li> <li>sync: add <code>{Receiver,UnboundedReceiver}::{sender_strong_count,sender_weak_count}</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6661">#6661</a>)</li> <li>sync: implement <code>Default</code> for <code>watch::Sender</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6626">#6626</a>)</li> <li>task: implement <code>Clone</code> for <code>AbortHandle</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6621">#6621</a>)</li> <li>task: stabilize <code>consume_budget</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6622">#6622</a>)</li> </ul> <h3>Changed</h3> <ul> <li>io: improve panic message of <code>ReadBuf::put_slice()</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6629">#6629</a>)</li> <li>io: read during write in <code>copy_bidirectional</code> and <code>copy</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6532">#6532</a>)</li> <li>runtime: replace <code>num_cpus</code> with <code>available_parallelism</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6709">#6709</a>)</li> <li>task: avoid stack overflow when passing large future to <code>block_on</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6692">#6692</a>)</li> <li>time: avoid traversing entries in the time wheel twice (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6584">#6584</a>)</li> <li>time: support <code>IntoFuture</code> with <code>timeout</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6666">#6666</a>)</li> <li>macros: support <code>IntoFuture</code> with <code>join!</code> and <code>select!</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6710">#6710</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>docs: fix docsrs builds with the fs feature enabled (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6585">#6585</a>)</li> <li>io: only use short-read optimization on known-to-be-compatible platforms (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6668">#6668</a>)</li> <li>time: fix overflow panic when using large durations with <code>Interval</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6612">#6612</a>)</li> </ul> <h3>Added (unstable)</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
f800875aff |
fix(relay): don't hang when connecting to OTLP exporter (#6034)
The dependency update in #6003 introduced a regression: Connecting to the OTLP exporter was hanging forever and thus the relay failed to start up. The hang seems to be related to _dropping_ the `meter_provider`. Looking at the changelog update, this change was actually called out: https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-otlp/CHANGELOG.md#v0170. By setting these providers globally, the relay starts up just fine. To ensure this doesn't regress again, we add an OTEL collector to our `docker-compose.yml` and configure the `relay-1` to connect to it. |
||
|
Thomas Eizinger
|
782b171cc1 |
chore(relay): always log setup on trace (#6031)
In staging and production, setting up the logger for the relay is a fairly complicated setup. To make debugging easier, we always log these initial steps on `TRACE` level until the real logger is initialised. |
||
|
dependabot[bot]
|
dae90d81e1 |
build(deps): bump opentelemetry dependencies (#6003)
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
dependabot[bot]
|
7be47f2c6e |
build(deps): Bump url from 2.5.0 to 2.5.2 in /rust (#6002)
Bumps [url](https://github.com/servo/rust-url) from 2.5.0 to 2.5.2. <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
6d09344521 |
build(deps): Bump uuid from 1.8.0 to 1.10.0 in /rust (#6005)
Bumps [uuid](https://github.com/uuid-rs/uuid) from 1.8.0 to 1.10.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/uuid-rs/uuid/releases">uuid's releases</a>.</em></p> <blockquote> <h2>1.10.0</h2> <h2>Deprecations</h2> <p>This release deprecates and renames the following functions:</p> <ul> <li><code>Builder::from_rfc4122_timestamp</code> -> <code>Builder::from_gregorian_timestamp</code></li> <li><code>Builder::from_sorted_rfc4122_timestamp</code> -> <code>Builder::from_sorted_gregorian_timestamp</code></li> <li><code>Timestamp::from_rfc4122</code> -> <code>Timestamp::from_gregorian</code></li> <li><code>Timestamp::to_rfc4122</code> -> <code>Timestamp::to_gregorian</code></li> </ul> <h2>What's Changed</h2> <ul> <li>Use const identifier in uuid macro by <a href="https://github.com/Vrajs16"><code>@Vrajs16</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/764">uuid-rs/uuid#764</a></li> <li>Rename most methods referring to RFC4122 by <a href="https://github.com/Mikopet"><code>@Mikopet</code></a> / <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/765">uuid-rs/uuid#765</a></li> <li>prepare for 1.10.0 release by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/766">uuid-rs/uuid#766</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/Vrajs16"><code>@Vrajs16</code></a> made their first contribution in <a href="https://redirect.github.com/uuid-rs/uuid/pull/764">uuid-rs/uuid#764</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/uuid-rs/uuid/compare/1.9.1...1.10.0">https://github.com/uuid-rs/uuid/compare/1.9.1...1.10.0</a></p> <h2>1.9.1</h2> <h2>What's Changed</h2> <ul> <li>Add an example of generating bulk v7 UUIDs by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/761">uuid-rs/uuid#761</a></li> <li>Avoid taking the shared lock when getting usable bits in Uuid::now_v7 by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/762">uuid-rs/uuid#762</a></li> <li>Prepare for 1.9.1 release by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/763">uuid-rs/uuid#763</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/uuid-rs/uuid/compare/1.9.0...1.9.1">https://github.com/uuid-rs/uuid/compare/1.9.0...1.9.1</a></p> <h2>1.9.0</h2> <h2><code>Uuid::now_v7()</code> is guaranteed to be monotonic</h2> <p>Before this release, <code>Uuid::now_v7()</code> would only use the millisecond-precision timestamp for ordering. It now also uses a global 42-bit counter that's re-initialized each millisecond so that the following will always pass:</p> <pre lang="rust"><code>let a = Uuid::now_v7(); let b = Uuid::now_v7(); <p>assert!(a < b);<br /> </code></pre></p> <h2>What's Changed</h2> <ul> <li>Add a get_node_id method for v1 and v6 UUIDs by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/748">uuid-rs/uuid#748</a></li> <li>Update atomic and zerocopy to latest by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/750">uuid-rs/uuid#750</a></li> <li>Add repository field to uuid-macro-internal crate by <a href="https://github.com/paolobarbolini"><code>@paolobarbolini</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/752">uuid-rs/uuid#752</a></li> <li>update docs to updated RFC (from 4122 to 9562) by <a href="https://github.com/Mikopet"><code>@Mikopet</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/753">uuid-rs/uuid#753</a></li> <li>Support counters in v7 UUIDs by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/755">uuid-rs/uuid#755</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/paolobarbolini"><code>@paolobarbolini</code></a> made their first contribution in <a href="https://redirect.github.com/uuid-rs/uuid/pull/752">uuid-rs/uuid#752</a></li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
da52c66023 |
refactor(clients): init PhoenixChannel in upper layers (#5884)
This represents a step towards #3837. Eventually, we'd like the abstractions of `Session` and `Eventloop` to go away entirely. For that, we need to thin them out. The introduction of `ConnectArgs` was already a hint that we are passing a lot of data across layers that we shouldn't. To avoid that, we can simply initialise `PhoenixChannel` earlier and thus each callsite can specify the desired configuration directly. I've left `ConnectArgs` intact to keep the diff small. |
||
|
Thomas Eizinger
|
aa279d7731 |
ci: never tolerate warnings in Rust code (#5893)
Our Rust CI runs various jobs in different configurations of packages and / or features. Currently, only the clippy job denies warnings which makes it possible that some code still generates warnings under particular configurations. To ensure we always fail on warnings, we set a global env var to deny warnings for all Rust CI jobs. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com> |
||
|
Gabi
|
5b0aaa6f81 |
fix(connlib): protect all sockets from routing loops (#5797)
Currently, only connlib's UDP sockets for sending and receiving STUN & WireGuard traffic are protected from routing loops. This is was done via the `Sockets::with_protect` function. Connlib has additional sockets though: - A TCP socket to the portal. - UDP & TCP sockets for DNS resolution via hickory. Both of these can incur routing loops on certain platforms which becomes evident as we try to implement #2667. To fix this, we generalise the idea of "protecting" a socket via a `SocketFactory` abstraction. By allowing the different platforms to provide a specialised `SocketFactory`, anything Linux-based can give special treatment to the socket before handing it to connlib. As an additional benefit, this allows us to remove the `Sockets` abstraction from connlib's API again because we can now initialise it internally via the provided `SocketFactory` for UDP sockets. --------- Signed-off-by: Gabi <gabrielalejandro7@gmail.com> Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Thomas Eizinger
|
c92dd559f7 |
chore(rust): format Cargo.toml using cargo-sort (#5851)
|