mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
1ac1bb044a
Bumps the sentry group in /rust with 2 updates: [sentry](https://github.com/getsentry/sentry-rust) and [sentry-tracing](https://github.com/getsentry/sentry-rust). Updates `sentry` from 0.42.0 to 0.43.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-rust/releases">sentry's releases</a>.</em></p> <blockquote> <h2>0.43.0</h2> <h3>Breaking changes</h3> <ul> <li>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The <code>tracing</code> integration now uses the tracing span name as the Sentry span name by default.</li> <li>Before this change, the span name would be set based on the <code>tracing</code> span target (<code><module>::<function></code> when using the <code>tracing::instrument</code> macro).</li> <li>The <code>tracing</code> integration now uses <code><span target>::<span name></code> as the default Sentry span op (i.e. <code><module>::<function></code> when using <code>tracing::instrument</code>).</li> <li>Before this change, the span op would be set based on the <code>tracing</code> span name.</li> <li>Read below to learn how to customize the span name and op.</li> <li>When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.</li> </ul> </li> <li>ref(tracing): use standard code attributes (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/899">#899</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>Logs now carry the attributes <code>code.module.name</code>, <code>code.file.path</code> and <code>code.line.number</code> standardized in OTEL to surface the respective information, in contrast with the previously sent <code>tracing.module_path</code>, <code>tracing.file</code> and <code>tracing.line</code>.</li> </ul> </li> <li>fix(actix): capture only server errors (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/877">#877</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The Actix integration now properly honors the <code>capture_server_errors</code> option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).</li> <li>Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.</li> <li>With this change, we capture errors returned by middleware only if those errors can be classified as server errors.</li> <li>There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.</li> </ul> </li> <li>fix: send trace origin correctly (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/906">#906</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li><code>TraceContext</code> now has an additional field <code>origin</code>, used to report which integration created a transaction.</li> </ul> </li> </ul> <h3>Behavioral changes</h3> <ul> <li>feat(tracing): send both breadcrumbs and logs by default (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/878">#878</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>If the <code>logs</code> feature flag is enabled, and <code>enable_logs: true</code> is set on your client options, the default Sentry <code>tracing</code> layer now sends logs for all events at or above INFO.</li> </ul> </li> </ul> <h3>Features</h3> <ul> <li> <p>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> <ul> <li>Additional special fields have been added that allow overriding certain data on the Sentry span: <ul> <li><code>sentry.op</code>: override the Sentry span op.</li> <li><code>sentry.name</code>: override the Sentry span name.</li> <li><code>sentry.trace</code>: given a string matching a valid <code>sentry-trace</code> header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid <code>sentry-trace</code> header or a trace is already started, this value is ignored.</li> </ul> </li> <li><code>sentry.op</code> and <code>sentry.name</code> can also be applied retroactively by declaring fields with value <code>tracing::field::Empty</code> and then recorded using <code>tracing::Span::record</code>.</li> <li>Example usage: <pre lang="rust"><code>#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... } </code></pre> </li> <li>Additional attributes are sent along with each span by default: <ul> <li><code>sentry.tracing.target</code>: corresponds to the <code>tracing</code> span's <code>metadata.target()</code></li> <li><code>code.module.name</code>, <code>code.file.path</code>, <code>code.line.number</code></li> </ul> </li> </ul> </li> <li> <p>feat(core): add Response context (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/874">#874</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> <ul> <li>The <code>Response</code> context can now be attached to events, to include information about HTTP responses such as headers, cookies and status code.</li> </ul> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-rust/blob/master/CHANGELOG.md">sentry's changelog</a>.</em></p> <blockquote> <h2>0.43.0</h2> <h3>Breaking changes</h3> <ul> <li>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The <code>tracing</code> integration now uses the tracing span name as the Sentry span name by default.</li> <li>Before this change, the span name would be set based on the <code>tracing</code> span target (<code><module>::<function></code> when using the <code>tracing::instrument</code> macro).</li> <li>The <code>tracing</code> integration now uses <code><span target>::<span name></code> as the default Sentry span op (i.e. <code><module>::<function></code> when using <code>tracing::instrument</code>).</li> <li>Before this change, the span op would be set based on the <code>tracing</code> span name.</li> <li>Read below to learn how to customize the span name and op.</li> <li>When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.</li> </ul> </li> <li>ref(tracing): use standard code attributes (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/899">#899</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>Logs now carry the attributes <code>code.module.name</code>, <code>code.file.path</code> and <code>code.line.number</code> standardized in OTEL to surface the respective information, in contrast with the previously sent <code>tracing.module_path</code>, <code>tracing.file</code> and <code>tracing.line</code>.</li> </ul> </li> <li>fix(actix): capture only server errors (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/877">#877</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The Actix integration now properly honors the <code>capture_server_errors</code> option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).</li> <li>Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.</li> <li>With this change, we capture errors returned by middleware only if those errors can be classified as server errors.</li> <li>There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.</li> </ul> </li> <li>fix: send trace origin correctly (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/906">#906</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li><code>TraceContext</code> now has an additional field <code>origin</code>, used to report which integration created a transaction.</li> </ul> </li> </ul> <h3>Behavioral changes</h3> <ul> <li>feat(tracing): send both breadcrumbs and logs by default (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/878">#878</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>If the <code>logs</code> feature flag is enabled, and <code>enable_logs: true</code> is set on your client options, the default Sentry <code>tracing</code> layer now sends logs for all events at or above INFO.</li> </ul> </li> </ul> <h3>Features</h3> <ul> <li> <p>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> <ul> <li>Additional special fields have been added that allow overriding certain data on the Sentry span: <ul> <li><code>sentry.op</code>: override the Sentry span op.</li> <li><code>sentry.name</code>: override the Sentry span name.</li> <li><code>sentry.trace</code>: given a string matching a valid <code>sentry-trace</code> header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid <code>sentry-trace</code> header or a trace is already started, this value is ignored.</li> </ul> </li> <li><code>sentry.op</code> and <code>sentry.name</code> can also be applied retroactively by declaring fields with value <code>tracing::field::Empty</code> and then recorded using <code>tracing::Span::record</code>.</li> <li>Example usage: <pre lang="rust"><code>#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... } </code></pre> </li> <li>Additional attributes are sent along with each span by default: <ul> <li><code>sentry.tracing.target</code>: corresponds to the <code>tracing</code> span's <code>metadata.target()</code></li> <li><code>code.module.name</code>, <code>code.file.path</code>, <code>code.line.number</code></li> </ul> </li> </ul> </li> <li> <p>feat(core): add Response context (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/874">#874</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="b08b24a057"><code>b08b24a</code></a> release: 0.43.0</li> <li><a href="1c08ca8671"><code>1c08ca8</code></a> ref(tracing): keep old span name as op instead of default (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/905">#905</a>)</li> <li><a href="75aff83c65"><code>75aff83</code></a> fix(tracing): skip default span attributes when propagating to event (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/904">#904</a>)</li> <li><a href="6b61b31367"><code>6b61b31</code></a> fix: send trace origin correctly (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/906">#906</a>)</li> <li><a href="75a8c03de7"><code>75a8c03</code></a> ref(tracing): use standard code attributes (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/899">#899</a>)</li> <li><a href="bbd667ab00"><code>bbd667a</code></a> meta: add pull request template (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/898">#898</a>)</li> <li><a href="5c8ab31b61"><code>5c8ab31</code></a> ref(tracing): rework <code>tracing</code> to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/887">#887</a>)</li> <li><a href="045c2e2fed"><code>045c2e2</code></a> feat(tracing): send both breadcrumbs and logs by default (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/878">#878</a>)</li> <li><a href="a5932c0295"><code>a5932c0</code></a> fix(transport): add rate limit for logs (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/894">#894</a>)</li> <li><a href="280dab99be"><code>280dab9</code></a> build(deps): bump tracing-subscriber from 0.3.19 to 0.3.20 (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/891">#891</a>)</li> <li>Additional commits viewable in <a href="https://github.com/getsentry/sentry-rust/compare/0.42.0...0.43.0">compare view</a></li> </ul> </details> <br /> Updates `sentry-tracing` from 0.42.0 to 0.43.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-rust/releases">sentry-tracing's releases</a>.</em></p> <blockquote> <h2>0.43.0</h2> <h3>Breaking changes</h3> <ul> <li>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The <code>tracing</code> integration now uses the tracing span name as the Sentry span name by default.</li> <li>Before this change, the span name would be set based on the <code>tracing</code> span target (<code><module>::<function></code> when using the <code>tracing::instrument</code> macro).</li> <li>The <code>tracing</code> integration now uses <code><span target>::<span name></code> as the default Sentry span op (i.e. <code><module>::<function></code> when using <code>tracing::instrument</code>).</li> <li>Before this change, the span op would be set based on the <code>tracing</code> span name.</li> <li>Read below to learn how to customize the span name and op.</li> <li>When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.</li> </ul> </li> <li>ref(tracing): use standard code attributes (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/899">#899</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>Logs now carry the attributes <code>code.module.name</code>, <code>code.file.path</code> and <code>code.line.number</code> standardized in OTEL to surface the respective information, in contrast with the previously sent <code>tracing.module_path</code>, <code>tracing.file</code> and <code>tracing.line</code>.</li> </ul> </li> <li>fix(actix): capture only server errors (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/877">#877</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The Actix integration now properly honors the <code>capture_server_errors</code> option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).</li> <li>Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.</li> <li>With this change, we capture errors returned by middleware only if those errors can be classified as server errors.</li> <li>There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.</li> </ul> </li> <li>fix: send trace origin correctly (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/906">#906</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li><code>TraceContext</code> now has an additional field <code>origin</code>, used to report which integration created a transaction.</li> </ul> </li> </ul> <h3>Behavioral changes</h3> <ul> <li>feat(tracing): send both breadcrumbs and logs by default (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/878">#878</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>If the <code>logs</code> feature flag is enabled, and <code>enable_logs: true</code> is set on your client options, the default Sentry <code>tracing</code> layer now sends logs for all events at or above INFO.</li> </ul> </li> </ul> <h3>Features</h3> <ul> <li> <p>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> <ul> <li>Additional special fields have been added that allow overriding certain data on the Sentry span: <ul> <li><code>sentry.op</code>: override the Sentry span op.</li> <li><code>sentry.name</code>: override the Sentry span name.</li> <li><code>sentry.trace</code>: given a string matching a valid <code>sentry-trace</code> header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid <code>sentry-trace</code> header or a trace is already started, this value is ignored.</li> </ul> </li> <li><code>sentry.op</code> and <code>sentry.name</code> can also be applied retroactively by declaring fields with value <code>tracing::field::Empty</code> and then recorded using <code>tracing::Span::record</code>.</li> <li>Example usage: <pre lang="rust"><code>#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... } </code></pre> </li> <li>Additional attributes are sent along with each span by default: <ul> <li><code>sentry.tracing.target</code>: corresponds to the <code>tracing</code> span's <code>metadata.target()</code></li> <li><code>code.module.name</code>, <code>code.file.path</code>, <code>code.line.number</code></li> </ul> </li> </ul> </li> <li> <p>feat(core): add Response context (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/874">#874</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> <ul> <li>The <code>Response</code> context can now be attached to events, to include information about HTTP responses such as headers, cookies and status code.</li> </ul> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-rust/blob/master/CHANGELOG.md">sentry-tracing's changelog</a>.</em></p> <blockquote> <h2>0.43.0</h2> <h3>Breaking changes</h3> <ul> <li>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The <code>tracing</code> integration now uses the tracing span name as the Sentry span name by default.</li> <li>Before this change, the span name would be set based on the <code>tracing</code> span target (<code><module>::<function></code> when using the <code>tracing::instrument</code> macro).</li> <li>The <code>tracing</code> integration now uses <code><span target>::<span name></code> as the default Sentry span op (i.e. <code><module>::<function></code> when using <code>tracing::instrument</code>).</li> <li>Before this change, the span op would be set based on the <code>tracing</code> span name.</li> <li>Read below to learn how to customize the span name and op.</li> <li>When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.</li> </ul> </li> <li>ref(tracing): use standard code attributes (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/899">#899</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>Logs now carry the attributes <code>code.module.name</code>, <code>code.file.path</code> and <code>code.line.number</code> standardized in OTEL to surface the respective information, in contrast with the previously sent <code>tracing.module_path</code>, <code>tracing.file</code> and <code>tracing.line</code>.</li> </ul> </li> <li>fix(actix): capture only server errors (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/877">#877</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The Actix integration now properly honors the <code>capture_server_errors</code> option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).</li> <li>Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.</li> <li>With this change, we capture errors returned by middleware only if those errors can be classified as server errors.</li> <li>There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.</li> </ul> </li> <li>fix: send trace origin correctly (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/906">#906</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li><code>TraceContext</code> now has an additional field <code>origin</code>, used to report which integration created a transaction.</li> </ul> </li> </ul> <h3>Behavioral changes</h3> <ul> <li>feat(tracing): send both breadcrumbs and logs by default (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/878">#878</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>If the <code>logs</code> feature flag is enabled, and <code>enable_logs: true</code> is set on your client options, the default Sentry <code>tracing</code> layer now sends logs for all events at or above INFO.</li> </ul> </li> </ul> <h3>Features</h3> <ul> <li> <p>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> <ul> <li>Additional special fields have been added that allow overriding certain data on the Sentry span: <ul> <li><code>sentry.op</code>: override the Sentry span op.</li> <li><code>sentry.name</code>: override the Sentry span name.</li> <li><code>sentry.trace</code>: given a string matching a valid <code>sentry-trace</code> header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid <code>sentry-trace</code> header or a trace is already started, this value is ignored.</li> </ul> </li> <li><code>sentry.op</code> and <code>sentry.name</code> can also be applied retroactively by declaring fields with value <code>tracing::field::Empty</code> and then recorded using <code>tracing::Span::record</code>.</li> <li>Example usage: <pre lang="rust"><code>#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... } </code></pre> </li> <li>Additional attributes are sent along with each span by default: <ul> <li><code>sentry.tracing.target</code>: corresponds to the <code>tracing</code> span's <code>metadata.target()</code></li> <li><code>code.module.name</code>, <code>code.file.path</code>, <code>code.line.number</code></li> </ul> </li> </ul> </li> <li> <p>feat(core): add Response context (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/874">#874</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="b08b24a057"><code>b08b24a</code></a> release: 0.43.0</li> <li><a href="1c08ca8671"><code>1c08ca8</code></a> ref(tracing): keep old span name as op instead of default (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/905">#905</a>)</li> <li><a href="75aff83c65"><code>75aff83</code></a> fix(tracing): skip default span attributes when propagating to event (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/904">#904</a>)</li> <li><a href="6b61b31367"><code>6b61b31</code></a> fix: send trace origin correctly (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/906">#906</a>)</li> <li><a href="75a8c03de7"><code>75a8c03</code></a> ref(tracing): use standard code attributes (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/899">#899</a>)</li> <li><a href="bbd667ab00"><code>bbd667a</code></a> meta: add pull request template (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/898">#898</a>)</li> <li><a href="5c8ab31b61"><code>5c8ab31</code></a> ref(tracing): rework <code>tracing</code> to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/887">#887</a>)</li> <li><a href="045c2e2fed"><code>045c2e2</code></a> feat(tracing): send both breadcrumbs and logs by default (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/878">#878</a>)</li> <li><a href="a5932c0295"><code>a5932c0</code></a> fix(transport): add rate limit for logs (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/894">#894</a>)</li> <li><a href="280dab99be"><code>280dab9</code></a> build(deps): bump tracing-subscriber from 0.3.19 to 0.3.20 (<a href="https://redirect.github.com/getsentry/sentry-rust/issues/891">#891</a>)</li> <li>Additional commits viewable in <a href="https://github.com/getsentry/sentry-rust/compare/0.42.0...0.43.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> Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
A modern alternative to legacy VPNs.
Overview
Firezone is an open source platform to securely manage remote access for any-sized organization. Unlike most VPNs, Firezone takes a granular, least-privileged approach to access management with group-based policies that control access to individual applications, entire subnets, and everything in between.
Features
Firezone is:
- Fast: Built on WireGuard® to be 3-4 times faster than OpenVPN.
- Scalable: Deploy two or more gateways for automatic load balancing and failover.
- Private: Peer-to-peer, end-to-end encrypted tunnels prevent packets from routing through our infrastructure.
- Secure: Zero attack surface thanks to Firezone's holepunching tech which establishes tunnels on-the-fly at the time of access.
- Open: Our entire product is open-source, allowing anyone to audit the codebase.
- Flexible: Authenticate users via email, Google Workspace, Okta, Entra ID, or OIDC and sync users and groups automatically.
- Simple: Deploy gateways and configure access in minutes with a snappy admin UI.
Firezone is not:
- A tool for creating bi-directional mesh networks
- A full-featured router or firewall
- An IPSec or OpenVPN server
Contents of this repository
This is a monorepo containing the full Firezone product, marketing website, and product documentation, organized as follows:
- elixir: Control plane and internal Elixir libraries:
- elixir/apps/web: Admin UI
- elixir/apps/api: API for Clients, Relays and Gateways.
- rust/: Data plane and internal Rust libraries:
- rust/gateway: Gateway - Tunnel server based on WireGuard and deployed to your infrastructure.
- rust/relay: Relay - STUN/TURN server to facilitate holepunching.
- rust/headless-client: Cross-platform CLI client.
- rust/gui-client: Cross-platform GUI client.
- swift/: macOS / iOS clients.
- kotlin/: Android / ChromeOS clients.
- website/: Marketing website and product documentation.
Quickstart
The quickest way to get started with Firezone is to sign up for an account at https://app.firezone.dev/sign_up.
Once you've signed up, follow the instructions in the welcome email to get started.
Frequently asked questions (FAQ)
Can I self-host Firezone?
Our license won't stop you from self-hosting the entire Firezone product top to bottom, but our internal APIs are changing rapidly so we can't meaningfully support self-hosting Firezone in production at this time.
If you're feeling especially adventurous and want to self-host Firezone for educational or hobby purposes, follow the instructions to spin up a local development environment in CONTRIBUTING.md.
The latest published clients (on App Stores and on
releases) are only guaranteed
to work with the managed version of Firezone and may not work with a self-hosted
portal built from this repository. This is because Apple and Google can
sometimes delay updates to their app stores, and so the latest published version
may not be compatible with the tip of main from this repository.
Therefore, if you're experimenting with self-hosting Firezone, you will probably want to use clients you build and distribute yourself as well.
See the READMEs in the following directories for more information on building each client:
- macOS / iOS: swift/apple
- Android / ChromeOS: kotlin/android
- Windows / Linux: rust/gui-client
How long will 0.7 be supported until?
Firezone 0.7 is currently end-of-life and has stopped receiving updates as of
January 31st, 2024. It will continue to be available indefinitely from the
legacy branch of this repo under the Apache 2.0 license.
How much does it cost?
We offer flexible per-seat monthly and annual plans for the cloud-managed version of Firezone, with optional invoicing for larger organizations. See our pricing page for more details.
Those experimenting with self-hosting can use Firezone for free without feature or seat limitations, but we can't provide support for self-hosted installations at this time.
Documentation
Additional documentation on general usage, troubleshooting, and configuration can be found at https://www.firezone.dev/kb.
Get Help
If you're looking for help installing, configuring, or using Firezone, check our community support options:
- Discussion Forums: Ask questions, report bugs, and suggest features.
- Join our Discord Server: Join live discussions, meet other users, and chat with the Firezone team.
- Open a PR: Contribute a bugfix or make a contribution to Firezone.
If you need help deploying or maintaining Firezone for your business, consider contacting our sales team to speak with a Firezone expert.
See all support options on our main support page.
Star History
Developing and Contributing
See CONTRIBUTING.md.
Security
See SECURITY.md.
License
Portions of this software are licensed as follows:
- All content residing under the "elixir/" directory of this repository, if that directory exists, is licensed under the "Elastic License 2.0" license defined in "elixir/LICENSE".
- All third party components incorporated into the Firezone Software are licensed under the original license provided by the owner of the applicable component.
- Content outside of the above mentioned directories or restrictions above is available under the "Apache 2.0 License" license as defined in "LICENSE".
WireGuard® is a registered trademark of Jason A. Donenfeld.