Presently, for each UDP packet that we process in `snownet`, we check if
we have already seen this local address of ours and if not, add it to
our list of host candidates. This is a safe way for ensuring that we
consider all addresses that we receive data on as ones that we tell our
peers that they should try and contact us on.
Performance profiling has shown that hashing the socket address of each
packet that is coming in is quite wasteful. We spend about 4-5% of our
main thread time doing this. For comparison, decrypting packets is only
about 30%.
Most of the time, we will already know about this address and therefore,
spending all this CPU time is completely pointless. At the same time
though, we need to be sure that we do discover our local address
correctly.
Inspired by STUN, we therefore move this responsibility to the
`allocation` module. The `allocation` module is responsible for
interacting with our TURN servers and will yield server-reflexive and
relay candidates as a result. It also knows, what the local address is
that it received traffic on so we simply extend that to yield host
candidates as well in addition to server-reflexive and relay candidates.
On my local machine, this bumps us across the 3.5 Gbits/sec mark:
```
Connecting to host 172.20.0.110, port 5201
[ 5] local 100.93.174.92 port 57890 connected to 172.20.0.110 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 319 MBytes 2.67 Gbits/sec 18 548 KBytes
[ 5] 1.00-2.00 sec 413 MBytes 3.46 Gbits/sec 4 884 KBytes
[ 5] 2.00-3.00 sec 417 MBytes 3.50 Gbits/sec 4 1.10 MBytes
[ 5] 3.00-4.00 sec 425 MBytes 3.56 Gbits/sec 415 785 KBytes
[ 5] 4.00-5.00 sec 430 MBytes 3.60 Gbits/sec 154 820 KBytes
[ 5] 5.00-6.00 sec 434 MBytes 3.64 Gbits/sec 251 793 KBytes
[ 5] 6.00-7.00 sec 436 MBytes 3.66 Gbits/sec 123 811 KBytes
[ 5] 7.00-8.00 sec 435 MBytes 3.65 Gbits/sec 2 788 KBytes
[ 5] 8.00-9.00 sec 423 MBytes 3.55 Gbits/sec 0 1.06 MBytes
[ 5] 9.00-10.00 sec 433 MBytes 3.63 Gbits/sec 8 1017 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 8.21 GBytes 3.53 Gbits/sec 1728 sender
[ 5] 0.00-20.00 sec 8.21 GBytes 3.53 Gbits/sec receiver
iperf Done.
```
These are otherwise hit pretty often in the hot-path and slow packet
routing down because tracing needs to evaluate whether it should log the
statement.
Despite still being in development, the `tauri-specta` project already
proves to be quite useful. It allows us to generate TypeScript bindings
for our commands and events, creating a type-safe contract between the
frontend and the backend.
For example, this ensures that the TypeScript code calls a command
actually with the required parameters and thus avoids runtime failures.
Similarly, the frontend can listen on type-safe events without having to
use any magic strings.
Whilst entering and leaving a span for every packet is very expensive,
doing the same whenever we make timeout related changes is just fine.
Thus, we re-introduce a span removed in #9949 but only for the
`handle_timeout` function.
This gives us the context of the connection ID for not just our own
logs, but also the ones from `boringtun`.
By chance, I've discovered in a CI failure that we won't be able to
handshake a new session if the `preshared_key` changes. This makes a lot
of sense. The `preshared_key` needs to be the same on both ends as it is
a shared secret that gets mixed into the Noise handshake.
In following sequence of events, we would thus previously run into a
"failed to decrypt handshake packet" scenario:
1. Client requests a connection.
2. Gateway authorizes the connection.
3. Portal restarts / gets deployed. To my knowledge, this will rotate
the `preshared_key` to a new secret. Restarting the portal also cuts all
WebSockets and therefore, the Gateways response never arrives.
4. Client reconnects to the WebSocket, requests a new connection.
5. Gateway reuses the local connection but this connection still uses
the old `preshared_key`!
6. Client needs to wait for the Gateway's ICE timeout before it can
establish a new connection.
How exactly (3) happens doesn't matter. There are probably other
conditions as to where the WebSocket connections get cut and we cannot
complete our connection handshake.
Previously, our idle timer was only driven by incoming and outgoing
packets. To detect whether the tunnel is idle, we checked whether either
the last incoming or last outgoing packet was more than 20s ago.
For one, having two timestamps here is unnecessarily complex. We can
simply combine them and always update this timestamp as `last_activity`.
Two, recently, we have started to also take into account not only
packets but other changes to the tunnel, such as an upsert of the
connection or adding new candidate. What we failed to do though, is
update these timestamps because their variable name was related to
packets and not to any activity.
The problem with not updating these timestamps however is that we will
very quickly move out of "connected" back to "idle" because the old
timestamps are still more than 20s ago. Hence, the previous fixes of
moving out of idle on new candidates and connection upsert were
ineffective.
By combining and renaming the timestamps, it is now much more obvious
that we need to update this timestamp in the respective handler
functions which then grants us another 20s of non-idling. This is
important for e.g. connection upserts to ensure the Gateway runs into an
ICE timeout within a short amount of time, should there be something
wrong with the connection that the Client just upserted.
As profiling shows, even if the log target isn't enabled, simply
checking whether or not it is enabled is a significant performance hit.
By guarding these behind `debug_assertions`, I was able to almost
achieve 3.75 Gbits/s locally (when rebased onto #9998). Obviously, this
doesn't quite translate into real-world improvements but it is
nonetheless a welcome improvement.
```
Connecting to host 172.20.0.110, port 5201
[ 5] local 100.93.174.92 port 34678 connected to 172.20.0.110 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 401 MBytes 3.37 Gbits/sec 14 644 KBytes
[ 5] 1.00-2.00 sec 448 MBytes 3.76 Gbits/sec 3 976 KBytes
[ 5] 2.00-3.00 sec 453 MBytes 3.80 Gbits/sec 43 979 KBytes
[ 5] 3.00-4.00 sec 449 MBytes 3.77 Gbits/sec 21 911 KBytes
[ 5] 4.00-5.00 sec 452 MBytes 3.79 Gbits/sec 4 1.15 MBytes
[ 5] 5.00-6.00 sec 451 MBytes 3.78 Gbits/sec 81 1.01 MBytes
[ 5] 6.00-7.00 sec 445 MBytes 3.73 Gbits/sec 39 705 KBytes
[ 5] 7.00-8.00 sec 436 MBytes 3.66 Gbits/sec 3 1016 KBytes
[ 5] 8.00-9.00 sec 460 MBytes 3.85 Gbits/sec 1 956 KBytes
[ 5] 9.00-10.00 sec 453 MBytes 3.80 Gbits/sec 0 1.19 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 4.34 GBytes 3.73 Gbits/sec 209 sender
[ 5] 0.00-10.00 sec 4.34 GBytes 3.73 Gbits/sec receiver
```
I didn't want to remove the `wire` logs entirely because they are quite
useful for debugging. However, they are also exactly this: A debugging
tool. In a production build, we are very unlikely to turn these on which
makes `debug_assertions` a good tool for keeping these around without
interfering with performance.
Our `ThreadedUdpSocket` uses a background thread for the actual socket
operation. It merely represents a handle to send and receive from these
sockets but not the socket itself. Dropping the handle will shutdown the
background thread but that is an asynchronous operation.
In order to be sure that we can rebind the same port, we need to wait
for the background thread to stop.
We thus add a `Drop` implementation for the `ThreadedUdpSocket` that
waits for its background thread to disappear before it continues.
Resolves: #9992
Currently, packets for allocations, i.e. from relays are parsed inside
the `Allocation` struct. We have one of those structs for each relay
that `snownet` is talking to. When we disconnect from a relay because it
is e.g. not responding, then we deallocate this struct. As a result,
message that arrive from this relay can no longer be handled. This can
happen when the response time is longer than our timeout.
These packets then fall-through and end up being logged as "packet has
unknown format".
To prevent this, we make the signature on `Allocation` strongly-typed
and expect a fully parsed `Message` to be given to us. This allows us to
parse the message early and discard it with a DEBUG log in case we don't
have the necessary local state to handle it.
The functionality here is essentially the same, we just change at what
level this is being logged at from WARN to DEBUG.
We have to make one additional adjustment to make this work: Guard all
messages to be parsed by any `Allocation` to come from port 3478. This
is the assigned port that all relays are expected to listen on. If we
don't have any local state for a given address, we cannot decide whether
it is a STUN message for an agent or a STUN message for a relay that we
have disconnected from. Therefore, we need to de-multiplex based on the
source port.
Bumps the flowbite group in /rust/gui-client with 1 update:
[flowbite-react](https://github.com/themesberg/flowbite-react/tree/HEAD/packages/ui).
Updates `flowbite-react` from 0.11.8 to 0.11.9
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/themesberg/flowbite-react/releases">flowbite-react's
releases</a>.</em></p>
<blockquote>
<h2>flowbite-react@0.11.9</h2>
<h3>Patch Changes</h3>
<ul>
<li><a
href="https://redirect.github.com/themesberg/flowbite-react/pull/1587">#1587</a>
<a
href="3028f83f89"><code>3028f83</code></a>
Thanks <a href="https://github.com/raahed"><code>@raahed</code></a>! -
feat(Datepicker): Implemented a filter function prop</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/themesberg/flowbite-react/blob/main/packages/ui/CHANGELOG.md">flowbite-react's
changelog</a>.</em></p>
<blockquote>
<h2>0.11.9</h2>
<h3>Patch Changes</h3>
<ul>
<li><a
href="https://redirect.github.com/themesberg/flowbite-react/pull/1587">#1587</a>
<a
href="3028f83f89"><code>3028f83</code></a>
Thanks <a href="https://github.com/raahed"><code>@raahed</code></a>! -
feat(Datepicker): Implemented a filter function prop</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="213be8eb96"><code>213be8e</code></a>
Version Packages (<a
href="https://github.com/themesberg/flowbite-react/tree/HEAD/packages/ui/issues/1590">#1590</a>)</li>
<li><a
href="3028f83f89"><code>3028f83</code></a>
feat: Add 'filterDate' prop function on Datepicker (<a
href="https://github.com/themesberg/flowbite-react/tree/HEAD/packages/ui/issues/1587">#1587</a>)</li>
<li>See full diff in <a
href="https://github.com/themesberg/flowbite-react/commits/flowbite-react@0.11.9/packages/ui">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Due to network partitions between the Client and the Portal, it is
possible that a Client requests a new connection, then disconnects from
the portal and re-requests the connection once it is reconnected.
On the Gateway, we would have already authorized the first request and
initialise our ICE agents with our local candidates. The second time
around, the connection would be reused. The Client however has lost its
state and therefore, we need to tell it our candidates again.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Room join requests on the portal are only valid whilst we have a
WebSocket connection. To make sure the portal processes all our requests
correctly, we need to hold all other messages back while we are waiting
to join the room.
If the connection flaps while we are waiting to join a room, we may have
a lingering join request that never gets fulfilled and thus blocks the
sending of messages forever.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Now that we are capable of migrating a connection to another relay with
#9979, our test suite exposed an edge-case: If we are in the middle of
migrating a connection, it could be that the idle timer triggers because
we have not seen any application traffic in the last 20s.
Moving to idle mode drastically reduces the number of STUN bindings we
send and if this happens whilst we are still checking candidates, the
nomination doesn't happen in time for our boringtun handshake to
succeed.
Thus, we add a condition to our idle timer to not trigger unless ICE has
completed and reports us as `connected`.
When looking at logs, reducing noise is critical to make it easier to
spot important information. When sending logs to Sentry, we currently
append the fields of certain spans to message to make the output similar
to that of `tracing_subscriber::fmt`.
The actual name of a field inside a span is separated from the span name
by a colon. For example, here is a log message as we see it in Sentry
today:
> handle_input:class=success response
handle_input:from=C1A0479AA153FACA0722A5DF76343CF2BEECB10E:3478
handle_input:method=binding handle_input:rtt=34.7479ms
handle_input:tid=BB30E859ED88FFDF0786B634 request=["Software(snownet;
session=BCA42EF159C794F41AE45BF5099E54D3A193A7184C4D2C3560C2FE49C4C6CFB7)"]
response=["Software(firezone-relay; rev=e4ba5a69)",
"XorMappedAddress(B824B4035A78A6B188EF38BE13AA3C1B1B1196D6:52625)"]
Really, what we would like to see is only this:
> class=success response
from=C1A0479AA153FACA0722A5DF76343CF2BEECB10E:3478 method=binding
rtt=34.7479ms tid=BB30E859ED88FFDF0786B634 request=["Software(snownet;
session=BCA42EF159C794F41AE45BF5099E54D3A193A7184C4D2C3560C2FE49C4C6CFB7)"]
response=["Software(firezone-relay; rev=e4ba5a69)",
"XorMappedAddress(B824B4035A78A6B188EF38BE13AA3C1B1B1196D6:52625)"]
The duplication of `handle_input:` is just noise. In our local log
output, we already strip the name of the span to make it easier to read.
Here we now also do the same for the logs reported to Sentry.
When looking through customer logs, we see a lot of "Resolved best route
outside of tunnel" messages. Those get logged every time we need to
rerun our re-implementation of Windows' weighting algorithm as to which
source interface / IP a packet should be sent from.
Currently, this gets cached in every socket instance so for the
peer-to-peer socket, this is only computed once per destination IP.
However, for DNS queries, we make a new socket for every query. Using a
new source port DNS queries is recommended to avoid fingerprinting of
DNS queries. Using a new socket also means that we need to re-run this
algorithm every time we make a DNS query which is why we see this log so
often.
To fix this, we need to share this cache across all UDP sockets. Cache
invalidation is one of the hardest problems in computer science and this
instance is no different. This cache needs to be reset every time we
roam as that changes the weighting of which source interface to use.
To achieve this, we extend the `SocketFactory` trait with a `reset`
method. This method is called whenever we roam and can then reset a
shared cache inside the `UdpSocketFactory`. The "source IP resolver"
function that is passed to the UDP socket now simply accesses this
shared cache and inserts a new entry when it needs to resolve the IP.
As an added benefit, this may speed up DNS queries on Windows a bit
(although I haven't benchmarked it). It should certainly drastically
reduce the amount of syscalls we make on Windows.
In #6876, we added functionality that would only make use of new remote
candidates whilst we haven't nominated a socket yet with the remote. The
reason for that was because in the described edge-case where relays
reboot or get replaced whilst the client is partitioned from the portal
(or we experience a connection hiccup), only one of the two peers, i.e.
Client or Gateway would migrate to the new relay, leaving the other one
in an inconsistent state.
Looking at recent customer logs, I've been seeing a lot of these
messages:
> Unknown connection or socket has already been nominated
For this particular customer, these are then very quickly followed by
ICE timeouts, leaving the connection unusable.
Considering that, I no longer think that the above change was a good
idea and we should instead always make use of all candidates that we are
given. What we are seeing is that in deployment scenarios where the
latency link between Client and Gateway is very short (5-10ms) yet the
latency to the portal is longer (~30-50ms), we trigger a race condition
where we are temporarily nominating a _peer-reflexive_ candidate pair
instead of a regular one. This happens because with such a short latency
link, Client and Gateway are _faster_ in sending back and forth several
STUN bindings than the control plane is in delivering all the
candidates.
Due to the functionality added in #6876, this then results in us not
accepting the candidates. It further appears that a nominated
peer-reflexive candidate does not provide a stable connection which is
why we then run into an ICE timeout, requiring Firezone to establish a
new connection only to have the same thing happen again.
This is very disruptive for the user experience as the connection only
works for a few moments at a time.
With #9793, we have actually added a feature that is also at play here.
Now that we don't immediately act on an ICE timeout, it is actually
possible for both Client and Gateway to migrate a connection to a
different relay, should the one that they are using get disconnected. In
#9793, we added a timeout of 2s for this.
To make this fully work, we need to patch str0m to transition to
`Checking` early. Presently, str0m would directly transition from
`Disconnected` to `Connected` in this case which in some of the
high-latency scenarios that we are testing in CI is not enough to
recover the connection within 2s. By transitioning to `Checking` early,
we abort this timer.
Related: https://github.com/algesten/str0m/pull/676
In case we received a newly nominated socket from `str0m` whilst our
connection was in idle mode, we mistakenly did not apply that and kept
using the old one. ICE would still be functioning in this case because
`str0m` would have updated its internal state but we would be sending
packets into Nirvana.
I don't think that this is likely to be hit in production though as it
would be quite unusual to receive a new nomination whilst the connection
was completely idle.
When encrypting IP packets, `snownet` needs to prepare a buffer where
the encrypted packet is going to end up. Depending on whether we are
sending data via a relayed connection or direct, this buffer needs to be
offset by 4 bytes to allow for the 4-byte channel-data header of the
TURN protocol.
At present, we always first encrypt the packet and then on-demand move
the packet by 4-bytes to the left if we **don't** need to send it via a
relay. Internally, this translates to a `memmove` instruction which
actually turns out to be very cheap (I couldn't measure a speed
difference between this and `main`).
All of this code has grown historically though so I figured, it is
better to clean it up a bit to first evaluate, whether we have a direct
or relayed connection and based on that, write the encrypted packet
directly to the front of the buffer or offset it by 4 bytes.
Profiling has shown that using a spinlock-based buffer pool is
marginally (~1%) faster than the mutex-based one because it resolves
contention quicker.
Profiling has shown that checking whether the level is enabled is
actually more expensive than checking whether the packet is a DNS
packet. This improves performance by about 3%.
These are flooding our monitoring infra and don't really add that much
value. Pretty much all of the processing the relay does is request in
and out and none of the spans are nested.
We can therefore almost 1-to-1 replicate the logging we do with spans by
adding the fields to each log message.
Resolves: #9954
Bumps the sentry group in /rust/gui-client with 2 updates:
[@sentry/core](https://github.com/getsentry/sentry-javascript) and
[@sentry/react](https://github.com/getsentry/sentry-javascript).
Updates `@sentry/core` from 9.34.0 to 9.40.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/getsentry/sentry-javascript/releases"><code>@sentry/core</code>'s
releases</a>.</em></p>
<blockquote>
<h2>9.40.0</h2>
<h3>Important Changes</h3>
<ul>
<li><strong>feat(browser): Add debugId sync APIs between web worker and
main thread (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/16981">#16981</a>)</strong></li>
</ul>
<p>This release adds two Browser SDK APIs to let the main thread know
about debugIds of worker files:</p>
<ul>
<li><code>webWorkerIntegration({worker})</code> to be used in the main
thread</li>
<li><code>registerWebWorker({self})</code> to be used in the web
worker</li>
</ul>
<pre lang="js"><code>// main.js
Sentry.init({...})
<p>const worker = new MyWorker(...);</p>
<p>Sentry.addIntegration(Sentry.webWorkerIntegration({ worker }));</p>
<p>worker.addEventListener('message', e => {...});<br />
</code></pre></p>
<pre lang="js"><code>// worker.js
Sentry.registerWebWorker({ self });
self.postMessage(...);
</code></pre>
<ul>
<li><strong>feat(core): Deprecate logger in favor of debug (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17040">#17040</a>)</strong></li>
</ul>
<p>The internal SDK <code>logger</code> export from
<code>@sentry/core</code> has been deprecated in favor of the
<code>debug</code> export. <code>debug</code> only exposes
<code>log</code>, <code>warn</code>, and <code>error</code> methods but
is otherwise identical to <code>logger</code>. Note that this
deprecation does not affect the <code>logger</code> export from other
packages (like <code>@sentry/browser</code> or
<code>@sentry/node</code>) which is used for Sentry Logging.</p>
<pre lang="js"><code>import { logger, debug } from '@sentry/core';
<p>// before<br />
logger.info('This is an info message');</p>
<p>// after<br />
debug.log('This is an info message');<br />
</code></pre></p>
<ul>
<li><strong>feat(node): Add OpenAI integration (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17022">#17022</a>)</strong></li>
</ul>
<p>This release adds official support for instrumenting OpenAI SDK calls
in with Sentry tracing, following OpenTelemetry semantic conventions for
Generative AI. It instruments:</p>
<ul>
<li><code>client.chat.completions.create()</code> - For chat-based
completions</li>
<li><code>client.responses.create()</code> - For the responses API</li>
</ul>
<pre lang="js"><code></tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/getsentry/sentry-javascript/blob/develop/CHANGELOG.md"><code>@sentry/core</code>'s
changelog</a>.</em></p>
<blockquote>
<h2>9.40.0</h2>
<h3>Important Changes</h3>
<ul>
<li><strong>feat(browser): Add debugId sync APIs between web worker and
main thread (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/16981">#16981</a>)</strong></li>
</ul>
<p>This release adds two Browser SDK APIs to let the main thread know
about debugIds of worker files:</p>
<ul>
<li><code>webWorkerIntegration({worker})</code> to be used in the main
thread</li>
<li><code>registerWebWorker({self})</code> to be used in the web
worker</li>
</ul>
<pre lang="js"><code>// main.js
Sentry.init({...})
<p>const worker = new MyWorker(...);</p>
<p>Sentry.addIntegration(Sentry.webWorkerIntegration({ worker }));</p>
<p>worker.addEventListener('message', e => {...});<br />
</code></pre></p>
<pre lang="js"><code>// worker.js
Sentry.registerWebWorker({ self });
self.postMessage(...);
</code></pre>
<ul>
<li><strong>feat(core): Deprecate logger in favor of debug (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17040">#17040</a>)</strong></li>
</ul>
<p>The internal SDK <code>logger</code> export from
<code>@sentry/core</code> has been deprecated in favor of the
<code>debug</code> export. <code>debug</code> only exposes
<code>log</code>, <code>warn</code>, and <code>error</code> methods but
is otherwise identical to <code>logger</code>. Note that this
deprecation does not affect the <code>logger</code> export from other
packages (like <code>@sentry/browser</code> or
<code>@sentry/node</code>) which is used for Sentry Logging.</p>
<pre lang="js"><code>import { logger, debug } from '@sentry/core';
<p>// before<br />
logger.info('This is an info message');</p>
<p>// after<br />
debug.log('This is an info message');<br />
</code></pre></p>
<ul>
<li><strong>feat(node): Add OpenAI integration (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17022">#17022</a>)</strong></li>
</ul>
<p>This release adds official support for instrumenting OpenAI SDK calls
in with Sentry tracing, following OpenTelemetry semantic conventions for
Generative AI. It instruments:</p>
<ul>
<li><code>client.chat.completions.create()</code> - For chat-based
completions</li>
<li><code>client.responses.create()</code> - For the responses API</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="cc51366965"><code>cc51366</code></a>
release: 9.40.0</li>
<li><a
href="a12c5a6ff6"><code>a12c5a6</code></a>
Merge pull request <a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17039">#17039</a>
from getsentry/prepare-release/9.40.0</li>
<li><a
href="d4ab7c09c1"><code>d4ab7c0</code></a>
meta(changelog): Update changelog for 9.40.0</li>
<li><a
href="f538ef024c"><code>f538ef0</code></a>
feat(node): Add OpenAI integration (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17022">#17022</a>)</li>
<li><a
href="53199420c4"><code>5319942</code></a>
feat(node-core): Expand <code>@opentelemetry/instrumentation</code>
range to cover `0.20...</li>
<li><a
href="962d6973cc"><code>962d697</code></a>
fix(core): Add missing <code>SentryDebugLogger</code> type export (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17046">#17046</a>)</li>
<li><a
href="779c15995c"><code>779c159</code></a>
chore(test-registry): Add more descriptive error code for common error
(<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/16790">#16790</a>)</li>
<li><a
href="6116610341"><code>6116610</code></a>
chore: Add external contributor to CHANGELOG.md (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17052">#17052</a>)</li>
<li><a
href="14c5d444cc"><code>14c5d44</code></a>
test(react): Pin react-router version for e2e test (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17051">#17051</a>)</li>
<li><a
href="163798656a"><code>1637986</code></a>
docs(bun): remove advice concerning unhandled exceptions (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17049">#17049</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/getsentry/sentry-javascript/compare/9.34.0...9.40.0">compare
view</a></li>
</ul>
</details>
<br />
Updates `@sentry/react` from 9.34.0 to 9.40.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/getsentry/sentry-javascript/releases"><code>@sentry/react</code>'s
releases</a>.</em></p>
<blockquote>
<h2>9.40.0</h2>
<h3>Important Changes</h3>
<ul>
<li><strong>feat(browser): Add debugId sync APIs between web worker and
main thread (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/16981">#16981</a>)</strong></li>
</ul>
<p>This release adds two Browser SDK APIs to let the main thread know
about debugIds of worker files:</p>
<ul>
<li><code>webWorkerIntegration({worker})</code> to be used in the main
thread</li>
<li><code>registerWebWorker({self})</code> to be used in the web
worker</li>
</ul>
<pre lang="js"><code>// main.js
Sentry.init({...})
<p>const worker = new MyWorker(...);</p>
<p>Sentry.addIntegration(Sentry.webWorkerIntegration({ worker }));</p>
<p>worker.addEventListener('message', e => {...});<br />
</code></pre></p>
<pre lang="js"><code>// worker.js
Sentry.registerWebWorker({ self });
self.postMessage(...);
</code></pre>
<ul>
<li><strong>feat(core): Deprecate logger in favor of debug (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17040">#17040</a>)</strong></li>
</ul>
<p>The internal SDK <code>logger</code> export from
<code>@sentry/core</code> has been deprecated in favor of the
<code>debug</code> export. <code>debug</code> only exposes
<code>log</code>, <code>warn</code>, and <code>error</code> methods but
is otherwise identical to <code>logger</code>. Note that this
deprecation does not affect the <code>logger</code> export from other
packages (like <code>@sentry/browser</code> or
<code>@sentry/node</code>) which is used for Sentry Logging.</p>
<pre lang="js"><code>import { logger, debug } from '@sentry/core';
<p>// before<br />
logger.info('This is an info message');</p>
<p>// after<br />
debug.log('This is an info message');<br />
</code></pre></p>
<ul>
<li><strong>feat(node): Add OpenAI integration (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17022">#17022</a>)</strong></li>
</ul>
<p>This release adds official support for instrumenting OpenAI SDK calls
in with Sentry tracing, following OpenTelemetry semantic conventions for
Generative AI. It instruments:</p>
<ul>
<li><code>client.chat.completions.create()</code> - For chat-based
completions</li>
<li><code>client.responses.create()</code> - For the responses API</li>
</ul>
<pre lang="js"><code></tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/getsentry/sentry-javascript/blob/develop/CHANGELOG.md"><code>@sentry/react</code>'s
changelog</a>.</em></p>
<blockquote>
<h2>9.40.0</h2>
<h3>Important Changes</h3>
<ul>
<li><strong>feat(browser): Add debugId sync APIs between web worker and
main thread (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/16981">#16981</a>)</strong></li>
</ul>
<p>This release adds two Browser SDK APIs to let the main thread know
about debugIds of worker files:</p>
<ul>
<li><code>webWorkerIntegration({worker})</code> to be used in the main
thread</li>
<li><code>registerWebWorker({self})</code> to be used in the web
worker</li>
</ul>
<pre lang="js"><code>// main.js
Sentry.init({...})
<p>const worker = new MyWorker(...);</p>
<p>Sentry.addIntegration(Sentry.webWorkerIntegration({ worker }));</p>
<p>worker.addEventListener('message', e => {...});<br />
</code></pre></p>
<pre lang="js"><code>// worker.js
Sentry.registerWebWorker({ self });
self.postMessage(...);
</code></pre>
<ul>
<li><strong>feat(core): Deprecate logger in favor of debug (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17040">#17040</a>)</strong></li>
</ul>
<p>The internal SDK <code>logger</code> export from
<code>@sentry/core</code> has been deprecated in favor of the
<code>debug</code> export. <code>debug</code> only exposes
<code>log</code>, <code>warn</code>, and <code>error</code> methods but
is otherwise identical to <code>logger</code>. Note that this
deprecation does not affect the <code>logger</code> export from other
packages (like <code>@sentry/browser</code> or
<code>@sentry/node</code>) which is used for Sentry Logging.</p>
<pre lang="js"><code>import { logger, debug } from '@sentry/core';
<p>// before<br />
logger.info('This is an info message');</p>
<p>// after<br />
debug.log('This is an info message');<br />
</code></pre></p>
<ul>
<li><strong>feat(node): Add OpenAI integration (<a
href="https://redirect.github.com/getsentry/sentry-javascript/pull/17022">#17022</a>)</strong></li>
</ul>
<p>This release adds official support for instrumenting OpenAI SDK calls
in with Sentry tracing, following OpenTelemetry semantic conventions for
Generative AI. It instruments:</p>
<ul>
<li><code>client.chat.completions.create()</code> - For chat-based
completions</li>
<li><code>client.responses.create()</code> - For the responses API</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="cc51366965"><code>cc51366</code></a>
release: 9.40.0</li>
<li><a
href="a12c5a6ff6"><code>a12c5a6</code></a>
Merge pull request <a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17039">#17039</a>
from getsentry/prepare-release/9.40.0</li>
<li><a
href="d4ab7c09c1"><code>d4ab7c0</code></a>
meta(changelog): Update changelog for 9.40.0</li>
<li><a
href="f538ef024c"><code>f538ef0</code></a>
feat(node): Add OpenAI integration (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17022">#17022</a>)</li>
<li><a
href="53199420c4"><code>5319942</code></a>
feat(node-core): Expand <code>@opentelemetry/instrumentation</code>
range to cover `0.20...</li>
<li><a
href="962d6973cc"><code>962d697</code></a>
fix(core): Add missing <code>SentryDebugLogger</code> type export (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17046">#17046</a>)</li>
<li><a
href="779c15995c"><code>779c159</code></a>
chore(test-registry): Add more descriptive error code for common error
(<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/16790">#16790</a>)</li>
<li><a
href="6116610341"><code>6116610</code></a>
chore: Add external contributor to CHANGELOG.md (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17052">#17052</a>)</li>
<li><a
href="14c5d444cc"><code>14c5d44</code></a>
test(react): Pin react-router version for e2e test (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17051">#17051</a>)</li>
<li><a
href="163798656a"><code>1637986</code></a>
docs(bun): remove advice concerning unhandled exceptions (<a
href="https://redirect.github.com/getsentry/sentry-javascript/issues/17049">#17049</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/getsentry/sentry-javascript/compare/9.34.0...9.40.0">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [zbus](https://github.com/dbus2/zbus) from 5.8.0 to 5.9.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/dbus2/zbus/releases">zbus's
releases</a>.</em></p>
<blockquote>
<h2>🔖 zbus 5.9.0</h2>
<ul>
<li>🧵 Remove deadlocks in Connection name request tasks, resulting in
leaks under certain
circumstances.</li>
<li>🐛 When registering names, allow name replacement by default.</li>
<li>✨ Allow setting request name flags in
<code>connection::Builder</code>.</li>
<li>✨ Proper Default impl for <code>RequestNameFlags</code>. This change
is theoretically an API break for
users who assumed the default value to be empty.</li>
<li>🧑💻 Add <code>fdo::StartServiceReply</code> type. In 6.0 this will be
the return type of
<code>fdo::DBusProxy::start_service_by_name</code>. For now, just
provide a <code>TryFrom<u32></code>.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="30487b8fdb"><code>30487b8</code></a>
Merge pull request <a
href="https://redirect.github.com/dbus2/zbus/issues/1434">#1434</a> from
zeenix/zb-release</li>
<li><a
href="4b7928d2f8"><code>4b7928d</code></a>
🔖 zb,zm: Release 5.9.0</li>
<li><a
href="d570c947ea"><code>d570c94</code></a>
📝 CONTRIBUTING: Link to gimoji's web interface</li>
<li><a
href="0bf6e14b54"><code>0bf6e14</code></a>
Merge pull request <a
href="https://redirect.github.com/dbus2/zbus/issues/1431">#1431</a> from
zeenix/name-request-defaults</li>
<li><a
href="ba2a40752d"><code>ba2a407</code></a>
🧵 zb: Remove deadlocks in Connection name request tasks</li>
<li><a
href="3d35496021"><code>3d35496</code></a>
🐛 zb: Allow name replacement by default</li>
<li><a
href="0ad37f317a"><code>0ad37f3</code></a>
📝 zb: Remove a bunch of unnecessary links</li>
<li><a
href="493a9943d6"><code>493a994</code></a>
Merge pull request <a
href="https://redirect.github.com/dbus2/zbus/issues/1429">#1429</a> from
valpackett/val/knrmmkqzrvyp</li>
<li><a
href="f2fb16fd18"><code>f2fb16f</code></a>
🧑💻 zb: add fdo::dbus::StartServiceReply type</li>
<li><a
href="f93584de1f"><code>f93584d</code></a>
⬆️ micro: Update winnow to v0.7.12 (<a
href="https://redirect.github.com/dbus2/zbus/issues/1428">#1428</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/dbus2/zbus/compare/zbus-5.8.0...zbus-5.9.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.140 to
1.0.141.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/serde-rs/json/releases">serde_json's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.141</h2>
<ul>
<li>Optimize string escaping during serialization (<a
href="https://redirect.github.com/serde-rs/json/issues/1273">#1273</a>,
thanks <a
href="https://github.com/conradludgate"><code>@conradludgate</code></a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="6843c3660e"><code>6843c36</code></a>
Release 1.0.141</li>
<li><a
href="6e2c21063a"><code>6e2c210</code></a>
Touch up PR 1273</li>
<li><a
href="623d9b47cf"><code>623d9b4</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/json/issues/1273">#1273</a>
from conradludgate/optimise-string-escaping</li>
<li><a
href="de70b7db1f"><code>de70b7d</code></a>
use unreachable_unchecked for escape table. use a second match to
roundtrip E...</li>
<li><a
href="f2d940dd54"><code>f2d940d</code></a>
replace start index with bytes slice reference</li>
<li><a
href="cd55b5a0ff"><code>cd55b5a</code></a>
Ignore mismatched_lifetime_syntaxes lint</li>
<li><a
href="c1826ebccc"><code>c1826eb</code></a>
Pin nightly toolchain used for miri job</li>
<li><a
href="8a56cfa6d0"><code>8a56cfa</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/json/issues/1248">#1248</a>
from jimmycathy/master</li>
<li><a
href="af3d80de56"><code>af3d80d</code></a>
chore: fix typo</li>
<li>See full diff in <a
href="https://github.com/serde-rs/json/compare/v1.0.140...v1.0.141">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
When being presented an invalid peer certificate, there is no reason why
we should retry the connection, it is unlikely to fix itself. Plus, the
certificate may get / be cached and a restart of the application is
necessary.
Resolves: #9944
This was exposed by #9846. It is being added here as a dedicated PR
because the compatibility tests would fail or at least be flaky for the
latest client release so we cannot add the integration test right away.
When receiving an `init` message from the portal, we will now revoke all
authorizations not listed in the `authorizations` list of the `init`
message.
We (partly) test this by introducing a new transition in our proptests
that de-authorizes a certain resource whilst the Gateway is simulated to
be partitioned. It is difficult to test that we cannot make a connection
once that has happened because we would have to simulate a malicious
client that knows about resources / connections or ignores the "remove
resource" message.
Testing this is deferred to a dedicated task. We do test that we hit the
code path of revoking the resource authorization and because the other
resources keep working, we also test that we are at least not revoking
the wrong ones.
Resolves: #9892
From Sentry reports and user-submitted logs, we know that it is possible
for Client and Gateway to de-sync in regards to what each other's public
key is. In such a scenario, ICE will succeed to make a connection but
`boringtun` will fail to handshake a tunnel. By default, `boringtun`
tries for 90s to handshake a session before it gives up and expires it.
In Firezone, the ICE agent takes care of establishing connectivity
whereas `boringtun` itself just encrypts and decrypts packets. As such,
if ICE is working, we know that packets aren't getting lost but instead,
there must be some other issue as to why we cannot establish a session.
To improve the UX in these error cases, we reduce the rekey-attempt-time
to 15s. This roughly matches our ICE timeout. Those 15s count from the
moment we send the first handshake which is just after ICE completes.
Thus we can be sure that after at most 15s, we either have a working
WireGuard session or the connection gets cleaned up.
Related: #9890
Related: #9850
In Docker environments, applying iptables rules to filter
container-container traffic on the Docker bridged network is not
reliable, leading to direct connections being established in our relayed
tests. To fix this, we insert the rules directly from the client
container itself.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
When we invalidate or discard an allocation, it may happen that a relay
still sends channel-data messages to us. We don't recognize those and
will therefore attempt to parse them as WireGuard packets, ultimately
ending in an "Packet has unknown format" error.
To avoid this, we check if the packet is a valid channel-data message
even if we presently don't have an allocation on the relay that is
sending us the packet. In those cases, we can stop processing the
packet, thus avoiding these errors from being logged.
When a connection is in idle-mode, it only sends a STUN request every 25
seconds. If the Client disconnects e.g. due to a network partition, it
may send a new connection intent later. If the Gateway's connection is
still around then because it was in idle mode, it won't send any
candidates to the remote, making the Client's connection fail with "no
candidates received".
To alleviate this, we wake a connection out of idle mode every time it
is being upserted. This ensures that the connection will fail within 15s
IF the above scenario happens, allowing the Client to reconnect within a
much shorter time-frame.
Note that attempting to repair such a connection is likely pointless. It
is much safer to discard it and let them both establish a new
connection.
Related: #9862
Whilst looking through the auth module of the relay, I noticed that we
unnecessarily convert back and forth between expiry timestamps and
username formats when we could just be using the already parsed version.
