We already use `vite` as a bundling tool but only to rollup some of the
pre-built files. This setup (and therefore our buildscripts) can be
massively simplified by instructing `vite` to also build our TypeScript
code and compile tailwind.
This makes it much easier to develop locally because one only needs to
run `pnpm vite build --watch` to keep everything up to date.
Running `clippy` first is more useful because it provides better
feedback around compile-errors. When working with cross-platform code,
it is often the case that one needs to push to CI to ensure everything
builds. Therefore, getting fast feedback is important.
GitHub's Windows runners are very slow. In order to not prolong CI runs
too much, we set the number of _additional_ proptest cases for Windows
to 0. This means we still run all the regression seeds that we've
accumulated in `proptest-regressions/tests.txt` and simply don't
generate any new ones on top of it.
This is also a good benchmark to ensure that our regression seeds cover
all cases that we are testing further down below using the coverage
grepping.
Related: #8948
By default, proptest runs all regression cases + 256 new ones. Given
that we run the tests on 3 different operating systems in various
versions each and that on each PR, we are likely hitting enough
different cases to detect any bugs.
Related: #8948
Bumps
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.49.50 to 2.50.4.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.50.4</h2>
<ul>
<li>
<p>Update <code>typos@latest</code> to 1.31.2.</p>
</li>
<li>
<p>Update <code>osv-scanner@latest</code> to 2.0.2.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.95.</p>
</li>
</ul>
<h2>2.50.3</h2>
<ul>
<li>Update <code>cargo-zigbuild@latest</code> to 0.20.0.</li>
</ul>
<h2>2.50.2</h2>
<ul>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.4.</p>
</li>
<li>
<p>Update <code>syft@latest</code> to 1.23.1.</p>
</li>
</ul>
<h2>2.50.1</h2>
<ul>
<li>
<p>Update <code>syft@latest</code> to 1.23.0.</p>
</li>
<li>
<p>Update <code>cargo-semver-checks@latest</code> to 0.41.0.</p>
</li>
</ul>
<h2>2.50.0</h2>
<ul>
<li>
<p>Support <code>taplo</code>. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/944">#944</a>,
thanks <a
href="https://github.com/vivienm"><code>@vivienm</code></a>)</p>
</li>
<li>
<p>Update <code>wasmtime@latest</code> to 32.0.0.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.133.</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<h2>[2.50.4] - 2025-05-01</h2>
<ul>
<li>
<p>Update <code>typos@latest</code> to 1.31.2.</p>
</li>
<li>
<p>Update <code>osv-scanner@latest</code> to 2.0.2.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.95.</p>
</li>
</ul>
<h2>[2.50.3] - 2025-04-26</h2>
<ul>
<li>Update <code>cargo-zigbuild@latest</code> to 0.20.0.</li>
</ul>
<h2>[2.50.2] - 2025-04-26</h2>
<ul>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.4.</p>
</li>
<li>
<p>Update <code>syft@latest</code> to 1.23.1.</p>
</li>
</ul>
<h2>[2.50.1] - 2025-04-25</h2>
<ul>
<li>
<p>Update <code>syft@latest</code> to 1.23.0.</p>
</li>
<li>
<p>Update <code>cargo-semver-checks@latest</code> to 0.41.0.</p>
</li>
</ul>
<h2>[2.50.0] - 2025-04-21</h2>
<ul>
<li>
<p>Support <code>taplo</code>. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/944">#944</a>,
thanks <a
href="https://github.com/vivienm"><code>@vivienm</code></a>)</p>
</li>
<li>
<p>Update <code>wasmtime@latest</code> to 32.0.0.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.133.</p>
</li>
</ul>
<h2>[2.49.50] - 2025-04-16</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.9.1.</li>
</ul>
<h2>[2.49.49] - 2025-04-13</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="33734a1186"><code>33734a1</code></a>
Release 2.50.4</li>
<li><a
href="014b96a1bb"><code>014b96a</code></a>
Update <code>typos@latest</code> to 1.31.2</li>
<li><a
href="35a81c61b8"><code>35a81c6</code></a>
Update <code>osv-scanner@latest</code> to 2.0.2</li>
<li><a
href="f3c9944420"><code>f3c9944</code></a>
Update <code>cargo-nextest@latest</code> to 0.9.95</li>
<li><a
href="ab3728c7ba"><code>ab3728c</code></a>
Release 2.50.3</li>
<li><a
href="6d5ef845d7"><code>6d5ef84</code></a>
Update <code>cargo-zigbuild@latest</code> to 0.20.0</li>
<li><a
href="52d0e7adc5"><code>52d0e7a</code></a>
Release 2.50.2</li>
<li><a
href="a69f86f003"><code>a69f86f</code></a>
Update <code>cargo-lambda@latest</code> to 1.8.4</li>
<li><a
href="b790d400b3"><code>b790d40</code></a>
Update <code>syft@latest</code> to 1.23.1</li>
<li><a
href="067268f3aa"><code>067268f</code></a>
Release 2.50.1</li>
<li>Additional commits viewable in <a
href="09dc018eee...33734a1186">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>
This tunnel throughput benchmark isn't a very useful benchmark and it is
very flaky. Remove it entirely until we can replace it with something
more robust and useful.
Resolves: #8172
When working on the Rust code of Firezone from a MacOS computer, it is
useful to have pretty much all of the code at least compile to ensure
detect problems early. Eventually, once we target features like a
headless MacOS client, some of these stubs will actually be filled in an
be functional.
Bumps
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.49.46 to 2.49.50.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.49.50</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.9.1.</li>
</ul>
<h2>2.49.49</h2>
<ul>
<li>Update <code>release-plz@latest</code> to 0.3.132.</li>
</ul>
<h2>2.49.48</h2>
<ul>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.131.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.94.</p>
</li>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.3.</p>
</li>
</ul>
<h2>2.49.47</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.9.0.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<ul>
<li>Update <code>release-plz@latest</code> to 0.3.133.</li>
</ul>
<h2>[2.49.50] - 2025-04-16</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.9.1.</li>
</ul>
<h2>[2.49.49] - 2025-04-13</h2>
<ul>
<li>Update <code>release-plz@latest</code> to 0.3.132.</li>
</ul>
<h2>[2.49.48] - 2025-04-11</h2>
<ul>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.131.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.94.</p>
</li>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.3.</p>
</li>
</ul>
<h2>[2.49.47] - 2025-04-09</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.9.0.</li>
</ul>
<h2>[2.49.46] - 2025-04-08</h2>
<ul>
<li>
<p>Update <code>espup@latest</code> to 0.15.0.</p>
</li>
<li>
<p>Update <code>trunk@latest</code> to 0.21.13.</p>
</li>
</ul>
<h2>[2.49.45] - 2025-04-06</h2>
<ul>
<li>
<p>Update <code>knope@latest</code> to 0.19.2.</p>
</li>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.12.3.</p>
</li>
</ul>
<h2>[2.49.44] - 2025-04-03</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.8.24.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="09dc018eee"><code>09dc018</code></a>
Release 2.49.50</li>
<li><a
href="2cd02413f6"><code>2cd0241</code></a>
Update <code>grcov@latest</code> to 0.9.1</li>
<li><a
href="be7c31b674"><code>be7c31b</code></a>
Release 2.49.49</li>
<li><a
href="a5bc3ba681"><code>a5bc3ba</code></a>
Update <code>release-plz@latest</code> to 0.3.132</li>
<li><a
href="5e434d4644"><code>5e434d4</code></a>
Release 2.49.48</li>
<li><a
href="e4c4a414ab"><code>e4c4a41</code></a>
Update <code>release-plz@latest</code> to 0.3.131</li>
<li><a
href="80a9f78f16"><code>80a9f78</code></a>
Update <code>cargo-nextest@latest</code> to 0.9.94</li>
<li><a
href="7722c176d5"><code>7722c17</code></a>
Update <code>cargo-lambda@latest</code> to 1.8.3</li>
<li><a
href="a48a50298f"><code>a48a502</code></a>
Release 2.49.47</li>
<li><a
href="63533c4988"><code>63533c4</code></a>
Update <code>grcov@latest</code> to 0.9.0</li>
<li>See full diff in <a
href="2db346588e...09dc018eee">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>
We no longer have multiple versions of `tauri-winrt-notification` in our
dependency tree and can therefore remove this exclusion rule.
To ensure that we don't forget to update these in the future, we now
deny the `unnecessary-skip` lint that warns us when we have one of those
entries.
Windows runners are very slow on GitHub actions. The Rust tests on
Windows are regularly the last CI job to finish. In order to speed up
overall CI runtime, reduce the number of cases we run on Windows to
1000. It doesn't really matter which OS we run these on as the proptests
are entirely platform-agnostic. We just need to get a good amount of
testcases in on each CI run.
Bumps
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.49.40 to 2.49.46.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.49.46</h2>
<ul>
<li>
<p>Update <code>espup@latest</code> to 0.15.0.</p>
</li>
<li>
<p>Update <code>trunk@latest</code> to 0.21.13.</p>
</li>
</ul>
<h2>2.49.45</h2>
<ul>
<li>
<p>Update <code>knope@latest</code> to 0.19.2.</p>
</li>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.12.3.</p>
</li>
</ul>
<h2>2.49.44</h2>
<ul>
<li>
<p>Update <code>grcov@latest</code> to 0.8.24.</p>
</li>
<li>
<p>Update <code>osv-scanner@latest</code> to 2.0.1.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.130.</p>
</li>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p>
</li>
<li>
<p>Downgrade <code>cargo-spellcheck@latest</code> to 0.15.1. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/932">#932</a>)</p>
</li>
</ul>
<h2>2.49.43</h2>
<ul>
<li>Update <code>syft@latest</code> to 1.22.0.</li>
</ul>
<h2>2.49.42</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.8.23.</li>
</ul>
<h2>2.49.41</h2>
<ul>
<li>Update <code>mdbook@latest</code> to 0.4.48.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<h2>[2.49.46] - 2025-04-08</h2>
<ul>
<li>
<p>Update <code>espup@latest</code> to 0.15.0.</p>
</li>
<li>
<p>Update <code>trunk@latest</code> to 0.21.13.</p>
</li>
</ul>
<h2>[2.49.45] - 2025-04-06</h2>
<ul>
<li>
<p>Update <code>knope@latest</code> to 0.19.2.</p>
</li>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.12.3.</p>
</li>
</ul>
<h2>[2.49.44] - 2025-04-03</h2>
<ul>
<li>
<p>Update <code>grcov@latest</code> to 0.8.24.</p>
</li>
<li>
<p>Update <code>osv-scanner@latest</code> to 2.0.1.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.130.</p>
</li>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p>
</li>
<li>
<p>Downgrade <code>cargo-spellcheck@latest</code> to 0.15.1. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/932">#932</a>)</p>
</li>
</ul>
<h2>[2.49.43] - 2025-04-01</h2>
<ul>
<li>Update <code>syft@latest</code> to 1.22.0.</li>
</ul>
<h2>[2.49.42] - 2025-04-01</h2>
<ul>
<li>Update <code>grcov@latest</code> to 0.8.23.</li>
</ul>
<h2>[2.49.41] - 2025-04-01</h2>
<ul>
<li>Update <code>mdbook@latest</code> to 0.4.48.</li>
</ul>
<h2>[2.49.40] - 2025-03-31</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="2db346588e"><code>2db3465</code></a>
Release 2.49.46</li>
<li><a
href="a214674956"><code>a214674</code></a>
Update <code>espup@latest</code> to 0.15.0</li>
<li><a
href="bba517d299"><code>bba517d</code></a>
Update <code>trunk@latest</code> to 0.21.13</li>
<li><a
href="d4635f2de6"><code>d4635f2</code></a>
Release 2.49.45</li>
<li><a
href="fcc9c5e18c"><code>fcc9c5e</code></a>
Update <code>knope@latest</code> to 0.19.2</li>
<li><a
href="256c1d84e7"><code>256c1d8</code></a>
Update <code>cargo-binstall@latest</code> to 1.12.3</li>
<li><a
href="57554aa960"><code>57554aa</code></a>
Update knope manifest</li>
<li><a
href="f1390fd0d8"><code>f1390fd</code></a>
Release 2.49.44</li>
<li><a
href="537312ee19"><code>537312e</code></a>
codegen: Exclude versions not released on crates.io from candidate for
"latest"</li>
<li><a
href="95bd642ae8"><code>95bd642</code></a>
Revert "codegen: Mark cargo-lambda 1.8.1 as broken"</li>
<li>Additional commits viewable in <a
href="daa3c1f1f9...2db346588e">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
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.49.9 to 2.49.40.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.49.40</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.31.1.</li>
</ul>
<h2>2.49.39</h2>
<ul>
<li>Downgrade <code>cargo-lambda@latest</code> to 1.8.0. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/923">#923</a>)</li>
</ul>
<h2>2.49.38</h2>
<ul>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p>
</li>
<li>
<p>Update <code>typos@latest</code> to 1.31.0.</p>
</li>
<li>
<p>Update <code>trunk@latest</code> to 0.21.12.</p>
</li>
</ul>
<h2>2.49.37</h2>
<ul>
<li>Update <code>trunk@latest</code> to 0.21.11.</li>
</ul>
<h2>2.49.36</h2>
<ul>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.129.</p>
</li>
<li>
<p>Update <code>protoc@latest</code> to 3.30.2.</p>
</li>
</ul>
<h2>2.49.35</h2>
<ul>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.93.</p>
</li>
<li>
<p>Update <code>typos@latest</code> to 1.30.3.</p>
</li>
<li>
<p>Update <code>wash@latest</code> to 0.41.0.</p>
</li>
</ul>
<h2>2.49.34</h2>
<ul>
<li>Update <code>knope@latest</code> to 0.19.0.</li>
</ul>
<h2>2.49.33</h2>
<ul>
<li>Update <code>release-plz@latest</code> to 0.3.128.</li>
</ul>
<h2>2.49.32</h2>
<ul>
<li>Update <code>wasmtime@latest</code> to 31.0.0.</li>
</ul>
<h2>2.49.31</h2>
<ul>
<li>
<p>Update <code>cargo-hack@latest</code> to 0.6.36.</p>
</li>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.12.2.</p>
</li>
</ul>
<h2>2.49.30</h2>
<ul>
<li>Update <code>dprint@latest</code> to 0.49.1.</li>
</ul>
<h2>2.49.29</h2>
<ul>
<li>
<p>Update <code>syft@latest</code> to 1.21.0.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.127.</p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<ul>
<li>Update <code>mdbook@latest</code> to 0.4.48.</li>
</ul>
<h2>[2.49.40] - 2025-03-31</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.31.1.</li>
</ul>
<h2>[2.49.39] - 2025-03-30</h2>
<ul>
<li>Downgrade <code>cargo-lambda@latest</code> to 1.8.0. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/923">#923</a>)</li>
</ul>
<h2>[2.49.38] - 2025-03-29</h2>
<ul>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p>
</li>
<li>
<p>Update <code>typos@latest</code> to 1.31.0.</p>
</li>
<li>
<p>Update <code>trunk@latest</code> to 0.21.12.</p>
</li>
</ul>
<h2>[2.49.37] - 2025-03-27</h2>
<ul>
<li>Update <code>trunk@latest</code> to 0.21.11.</li>
</ul>
<h2>[2.49.36] - 2025-03-27</h2>
<ul>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.129.</p>
</li>
<li>
<p>Update <code>protoc@latest</code> to 3.30.2.</p>
</li>
</ul>
<h2>[2.49.35] - 2025-03-25</h2>
<ul>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.93.</p>
</li>
<li>
<p>Update <code>typos@latest</code> to 1.30.3.</p>
</li>
<li>
<p>Update <code>wash@latest</code> to 0.41.0.</p>
</li>
</ul>
<h2>[2.49.34] - 2025-03-24</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="daa3c1f1f9"><code>daa3c1f</code></a>
Release 2.49.40</li>
<li><a
href="f51cb331c7"><code>f51cb33</code></a>
Update <code>typos@latest</code> to 1.31.1</li>
<li><a
href="6aca1cfa12"><code>6aca1cf</code></a>
Release 2.49.39</li>
<li><a
href="afd4ec3cf7"><code>afd4ec3</code></a>
Update changelog</li>
<li><a
href="3aab944b2c"><code>3aab944</code></a>
codegen: Mark cargo-lambda 1.8.1 as broken</li>
<li><a
href="9cd3d1b2b5"><code>9cd3d1b</code></a>
Update cargo-lambda manifest</li>
<li><a
href="1c861c252b"><code>1c861c2</code></a>
Release 2.49.38</li>
<li><a
href="ec15fa7ca8"><code>ec15fa7</code></a>
Update cspell dictionary</li>
<li><a
href="7b00681e7b"><code>7b00681</code></a>
Revert "tools: Pin cspell to 8.17.5"</li>
<li><a
href="0e9faa0611"><code>0e9faa0</code></a>
Update <code>cargo-lambda@latest</code> to 1.8.1</li>
<li>Additional commits viewable in <a
href="0b63bc859f...daa3c1f1f9">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>
## Abstract
This pull-request implements the first stage of off-loading routing of
TURN data channel messages to the kernel via an eBPF XDP program. In
particular, the eBPF kernel implemented here **only** handles the
decapsulation of IPv4 data channel messages into their embedded UDP
payload. Implementation of other data paths, such as the receiving of
UDP traffic on an allocation and wrapping it in a TURN channel data
message is deferred to a later point for reasons explained further down.
As it stands, this PR implements the bare minimum for us to start
experimenting and benefiting from eBPF. It is already massive as it is
due to the infrastructure required for actually doing this. Let's dive
into it!
## A refresher on TURN channel-data messages
TURN specifies a channel-data message for relaying data between two
peers. A channel data message has a fixed 4-byte header:
- The first two bytes specify the channel number
- The second two bytes specify the length of the encapsulated payload
Like all TURN traffic, channel data messages run over UDP by default,
meaning this header sits at the very front of the UDP payload. This will
be important later.
After making an allocation with a TURN server (i.e. reserving a port on
the TURN server's interfaces), a TURN client can bind channels on that
allocation. As such, channel numbers are scoped to a client's
allocation. Channel numbers are allocated by the client within a given
range (0x4000 - 0x4FFF). When binding a channel, the client specifies
the remote's peer address that they'd like the data sent on the channel
to be sent to.
Given this setup, when a TURN server receives a channel data message, it
first looks at the sender's IP + port to infer the allocation (a client
can only ever have 1 allocation at a time). Within that allocation, the
server then looks for the channel number and retrieves the target socket
address from that. The allocation itself is a port on the relay's
interface. With that, we can now "unpack" the payload of the channel
data message and rewrite it to the new receiver:
- The new source IP can be set from the old dst IP (when operating in
user-space mode this is irrelevant because we are working with the
socket API).
- The new source port is the client's allocation.
- The new destination IP is retrieved from the mapping retrieved via the
channel number.
- The new destination port is retrieved from the mapping retrieved via
the channel number.
Last but not least, all that is left is removing the channel data header
from the UDP payload and we can send out the packet. In other words, we
need to cut off the first 4 bytes of the UDP payload.
## User-space relaying
At present, we implement the above flow in user-space. This is tricky to
do because we need to bind _many_ sockets, one for each possible
allocation port (of which there can be 16383). The actual work to be
done on these packets is also extremely minimal. All we do is cut off
(or add on) the data-channel header. Benchmarks show that we spend
pretty much all of our time copying data between user-space and
kernel-space. Cutting this out should give us a massive increase in
performance.
## Implementing an eBPF XDP TURN router
eBPF has been shown to be a very efficient way of speeding up a TURN
server [0]. After many failed experiments (e.g. using TC instead of XDP)
and countless rabbit-holes, we have also arrived at the design
documented within the paper. Most notably:
- The eBPF program is entirely optional. We try to load it on startup,
but if that fails, we will simply use the user-space mode.
- Retaining the user-space mode is also important because under certain
circumstances, the eBPF kernel needs to pass on the packet, for example,
when receiving IPv4 packets with options. Those make the header
dynamically-sized which makes further processing difficult because the
eBPF verifier disallows indexing into the packet with data derived from
the packet itself.
- In order to add/remove the channel-data header, we shift the packet
headers backwards / forwards and leave the payload in place as the
packet headers are constant in size and can thus easily and cheaply be
copied out.
In order to perform the relaying flow explained above, we introduce maps
that are shared with user-space. These maps go from a tuple of
(client-socket, channel-number) to a tuple of (allocation-port,
peer-socket) and thus give us all the data necessary to rewrite the
packet.
## Integration with our relay
Last but not least, to actually integrate the eBPF kernel with our
relay, we need to extend the `Server` with two more events so we can
learn, when channel bindings are created and when they expire. Using
these events, we can then update the eBPF maps accordingly and therefore
influence the routing behaviour in the kernel.
## Scope
What is implemented here is only one of several possible data paths.
Implementing the others isn't conceptually difficult but it does
increase the scope. Landing something that already works allows us to
gain experience running it in staging (and possibly production).
Additionally, I've hit some issues with the eBPF verifier when adding
more codepaths to the kernel. I expect those to be possible to resolve
given sufficient debugging but I'd like to do so after merging this.
---
Depends-On: #8506
Depends-On: #8507
Depends-On: #8500Resolves: #8501
[0]: https://dl.acm.org/doi/pdf/10.1145/3609021.3609296
For #8501, we need to install a nightly toolchain in our CI system in
order to compile to eBPF kernel. We already use a nightly toolchain for
one of the static analysis tools.
In this PR, we extend our `setup-rust` action to install the nightly
toolchain for us which allows us to reuse that later.
A sizeable chunk of Firezone's Rust components deal with parsing,
manipulating and emitting DNS queries and responses. The API surface of
DNS is quite large and to make handling of all corner-cases easier, we
depend on the `domain` library to do the heavy-lifting for us.
For better or worse, `domain` follows a lazy-parsing approach. Thus,
creating a new DNS message doesn't actually verify that it is in fact
valid. Within Firezone, we make several assumptions around DNS messages,
such as that they will only ever contain a single question.
Historically, DNS allows for multiple questions per query but in
practise, nobody uses that.
Due to how we handle DNS in Firezone, manipulating these messages
happens in multiple places. That combined with the lazy-parsing approach
from `domain` warrants having our own `dns-types` library that wraps
`domain` and provides us with types that offer the interface we need in
the rest of the codebase.
Resolves: #7019
Search domains are a way of performing a DNS lookup without typing the
full-qualified domain name. For example, with a search domain of
`example.com`, performing a DNS query for `app` will automatically
expand the query to `app.example.com`. At present, this doesn't work
with Firezone because there is no way to configure an account-wide
search-domain.
With this PR, we extend the `Interface` message sent by the portal to
also include an optional `search_domain` field that must be a valid
domain name. If set, `connlib`'s DNS stub resolver will now append this
domain to all single-label queries and match the resulting domain
against all active DNS resource.
On Linux - with `systemd-resolved` as the DNS backend - we need to set
the search domain on the TUN interface as well and enable LLMNR in order
to be able to intercept these queries. `resolved` expands the query for
us, however, meaning with this configuration, we don't actually receive
a single-label query in `connlib`. Instead, we directly see
`app.example.com` when we type `host app` or `dig +search app` and have
`example.com` as our search domain.
MacOS has a similar system but with a different fallack. There, the
operating system will first try all configured search domains on the
system (typically just the ones set prior to Firezone starting), and
send queries for FQDN to all resolvers. If none of the resolvers
(including Firezone's stub resolver) return results, it sends the
single-label query directly to the primary resolver. To handle this
case, Firezone needs to know about the search-domain and expand it
itself when it receives the single-label query. In the future, we may
want to look into how we can configure MacOS such that it performs this
expansion for us.
On Windows and Android, queries for a single-label domain will be
directly sent to Firezone's stub resolver where we then hit the same
codepath as explained above.
Specifically, the way this codepath works is that if we receive a
single-label query AND we have a search-domain set, we expand it and
match that particular query against our list of resources. In every
other case, we continue on with the single-label domain.
Related: #8365Fixes: #8377
## Description
We want to resolve DNS queries of type SRV & TXT for DNS resources
within the network context of the site that is hosting the DNS resource
itself. This allows admins to e.g. deploy dedicated nameservers into
those sites and have them resolve their SRV and TXT records to names
that are scoped to that particular site.
SRV records themselves return more domains which - if they are
configured as DNS resources - will be intercepted and then routed to the
correct site.
Prior to this PR, SRV & TXT records got resolved by the DNS server
configured on the client (or the server defined in the Firezone portal),
even if the domain in question was a DNS resource. This effectively
meant that those SRV records have to be valid globally and could not be
specific to the site that the DNS resource is hosted in.
## Example
Say we have these wildcard DNS resources:
- `**.department-a.example.com`
- `**.department-b.example.com`
Each of these DNS resources is assigned to a different site. If we now
issue an SRV DNS query to `_my-service.department-a.example.com`, we may
receive back the following records:
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service1.department-a.example.com.`
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service2.department-a.example.com.`
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service3.department-a.example.com.`
Notice how the SRV records point to domains that will also match the
wildcard DNS resource above! If that is the case, Firezone will also
intercept A & AAAA queries for this service (which are a natural
follow-up from an application making an SRV query). As a result, traffic
for `my-service1.department-a.example.com` will be routed to the same
site the DNS resource is defined in. If the returned domains don't match
the wildcard DNS resource, the traffic will either not be intercepted at
all (if it is not a DNS resource) or routed to whichever site defines
the corresponding DNS resource.
All of these scenarios may be what the admin wants. If the SRV records
defined for the DNS resource are globally valid (and e.g. not even
resources), then resolving them using the Client's system resolver may
be all that is needed. If the services are running in a dedicated site,
that traffic should indeed be routed to that site.
As such, Firezone itself cannot make any assumption about the structure
of these records at all. The only thing that is enabled with this PR is
that IF the structure happens to match the same DNS resource, it allows
admins to deploy site-specific services that resolve their concrete
domains via SRV records.
## Testing
The implementation is tested using our property-based testing framework.
In order to cover these cases, we introduce the notion of site-specific
DNS records which are sampled when we create each individual Gateway.
When selecting a domain to query for, all global DNS records and the
site-specific ones are merged and a domain name and query type is chosen
at random.
At present, this testing framework does not assert that the DNS response
itself is correct, i.e. that it actually returned the site-specific
record. We don't assert this for any other DNS queries, hence this is
left for a future extension. We do assert using our regression grep's
that we hit the codepath of querying an SRV or TXT record for a DNS
resource.
Related: #8221
Bumps
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.47.32 to 2.49.9.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.49.9</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.30.0.</li>
</ul>
<h2>2.49.8</h2>
<ul>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.11.2.</p>
</li>
<li>
<p>Update <code>cargo-audit@latest</code> to 0.21.2.</p>
</li>
</ul>
<h2>2.49.7</h2>
<ul>
<li>Update <code>cargo-deny@latest</code> to 0.18.1.</li>
</ul>
<h2>2.49.6</h2>
<ul>
<li>Update <code>cargo-lambda@latest</code> to 1.7.0.</li>
</ul>
<h2>2.49.5</h2>
<ul>
<li>
<p>Update <code>wasmtime@latest</code> to 30.0.2.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.123.</p>
</li>
</ul>
<h2>2.49.4</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.29.10.</li>
</ul>
<h2>2.49.3</h2>
<ul>
<li>
<p>Update <code>wash@latest</code> to 0.39.0.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.92.</p>
</li>
</ul>
<h2>2.49.2</h2>
<ul>
<li>
<p>Update <code>sccache@latest</code> to 0.10.0.</p>
</li>
<li>
<p>Update <code>cargo-machete@latest</code> to 0.8.0.</p>
</li>
</ul>
<h2>2.49.1</h2>
<ul>
<li>Update <code>cargo-deny@latest</code> to 0.18.0.</li>
</ul>
<h2>2.49.0</h2>
<ul>
<li>Allow installing pre-release versions using binstall. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/868">#868</a>)</li>
</ul>
<h2>2.48.22</h2>
<ul>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.11.1.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.122.</p>
</li>
</ul>
<h2>2.48.21</h2>
<ul>
<li>
<p>Update <code>wasmtime@latest</code> to 30.0.1.</p>
</li>
<li>
<p>Update <code>syft@latest</code> to 1.20.0.</p>
</li>
</ul>
<h2>2.48.20</h2>
<ul>
<li>Update <code>cargo-udeps@latest</code> to 0.1.55.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<h2>[2.49.9] - 2025-03-01</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.30.0.</li>
</ul>
<h2>[2.49.8] - 2025-02-28</h2>
<ul>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.11.2.</p>
</li>
<li>
<p>Update <code>cargo-audit@latest</code> to 0.21.2.</p>
</li>
</ul>
<h2>[2.49.7] - 2025-02-27</h2>
<ul>
<li>Update <code>cargo-deny@latest</code> to 0.18.1.</li>
</ul>
<h2>[2.49.6] - 2025-02-27</h2>
<ul>
<li>Update <code>cargo-lambda@latest</code> to 1.7.0.</li>
</ul>
<h2>[2.49.5] - 2025-02-25</h2>
<ul>
<li>
<p>Update <code>wasmtime@latest</code> to 30.0.2.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.123.</p>
</li>
</ul>
<h2>[2.49.4] - 2025-02-25</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.29.10.</li>
</ul>
<h2>[2.49.3] - 2025-02-25</h2>
<ul>
<li>
<p>Update <code>wash@latest</code> to 0.39.0.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.92.</p>
</li>
</ul>
<h2>[2.49.2] - 2025-02-25</h2>
<ul>
<li>Update <code>sccache@latest</code> to 0.10.0.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0b63bc859f"><code>0b63bc8</code></a>
Release 2.49.9</li>
<li><a
href="366fcd03e0"><code>366fcd0</code></a>
Update <code>typos@latest</code> to 1.30.0</li>
<li><a
href="dccf3df6e0"><code>dccf3df</code></a>
Release 2.49.8</li>
<li><a
href="a1324e40ca"><code>a1324e4</code></a>
Update <code>cargo-binstall@latest</code> to 1.11.2</li>
<li><a
href="f0776fc234"><code>f0776fc</code></a>
Update <code>cargo-audit@latest</code> to 0.21.2</li>
<li><a
href="ada1a57be8"><code>ada1a57</code></a>
Release 2.49.7</li>
<li><a
href="afc83a47c0"><code>afc83a4</code></a>
Update <code>cargo-deny@latest</code> to 0.18.1</li>
<li><a
href="3fc1605ecf"><code>3fc1605</code></a>
Release 2.49.6</li>
<li><a
href="85ca29eaeb"><code>85ca29e</code></a>
Update <code>cargo-lambda@latest</code> to 1.7.0</li>
<li><a
href="93a6e1f102"><code>93a6e1f</code></a>
ci: Open update manifest PR also from workflow_dispatch</li>
<li>Additional commits viewable in <a
href="65835784ac...0b63bc859f">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>
This publishes the windows headless client using the same convention set
forth by the linux headless client.
Docs and website changes will come in a subsequent PR.
Related: #3782Resolves: #8046
Bumps
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.47.30 to 2.47.32.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.47.32</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.29.5.</li>
</ul>
<h2>2.47.31</h2>
<ul>
<li>Fix checksum error with <code>wash@0.38.0</code> on macOS. (They
rebuilt binaries for some reason.)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<h2>[2.47.32] - 2025-01-31</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.29.5.</li>
</ul>
<h2>[2.47.31] - 2025-01-30</h2>
<ul>
<li>Fix checksum error with <code>wash@0.38.0</code> on macOS. (They
rebuilt binaries for some reason.)</li>
</ul>
<h2>[2.47.30] - 2025-01-28</h2>
<ul>
<li>
<p>Support <code>cargo-cyclonedx</code> on x86_64 Linux (musl).</p>
</li>
<li>
<p>Support installing native binary for <code>cargo-cyclonedx</code> on
AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p>
</li>
<li>
<p>Update <code>cargo-cyclonedx@latest</code> to 0.5.7.</p>
</li>
</ul>
<h2>[2.47.29] - 2025-01-28</h2>
<ul>
<li>
<p>Support <code>cargo-semver-checks</code> on AArch64 Linux.</p>
</li>
<li>
<p>Support <code>cargo-zigbuild</code> on x86_64 macOS.</p>
</li>
<li>
<p>Support installing native binary for <code>mdbook</code> and
<code>shellcheck</code> on AArch64 macOS. (Previously x86_64 macOS
binary is used as fallback.)</p>
</li>
<li>
<p>Support installing native binary for <code>just</code> and
<code>sccache</code> on AArch64 Windows. (Previously x86_64 Windows
binary is used as fallback.)</p>
</li>
<li>
<p>Update <code>mdbook@latest</code> to 0.4.44.</p>
</li>
<li>
<p>Update <code>cargo-semver-checks@latest</code> to 0.39.0.</p>
</li>
</ul>
<h2>[2.47.28] - 2025-01-28</h2>
<p>No change on the <code>install-action</code> itself.</p>
<ul>
<li>
<p>Provide <code>install-action-manifest-schema</code> crate to access
to the <code>install-action</code> manifests from Rust code. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/657">#657</a>,
thanks <a
href="https://github.com/NobodyXu"><code>@NobodyXu</code></a>)</p>
<p>This is being considered for use to speed up
<code>cargo-binstall</code> in the future.</p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="65835784ac"><code>6583578</code></a>
Release 2.47.32</li>
<li><a
href="01f3d2d227"><code>01f3d2d</code></a>
Update <code>typos@latest</code> to 1.29.5</li>
<li><a
href="76a1fec160"><code>76a1fec</code></a>
Release 2.47.31</li>
<li><a
href="78b9ec82a6"><code>78b9ec8</code></a>
Update changelog</li>
<li><a
href="be22d29d34"><code>be22d29</code></a>
Fix clippy::unnecessary_semicolon warning</li>
<li><a
href="e466aa8e34"><code>e466aa8</code></a>
Update wash manifest</li>
<li>See full diff in <a
href="afbe5c1715...65835784ac">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
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.47.11 to 2.47.30.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.47.30</h2>
<ul>
<li>
<p>Support <code>cargo-cyclonedx</code> on x86_64 Linux (musl).</p>
</li>
<li>
<p>Support installing native binary for <code>cargo-cyclonedx</code> on
AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p>
</li>
<li>
<p>Update <code>cargo-cyclonedx@latest</code> to 0.5.7.</p>
</li>
</ul>
<h2>2.47.29</h2>
<ul>
<li>
<p>Support <code>cargo-semver-checks</code> on AArch64 Linux.</p>
</li>
<li>
<p>Support <code>cargo-zigbuild</code> on x86_64 macOS.</p>
</li>
<li>
<p>Support installing native binary for <code>mdbook</code> and
<code>shellcheck</code> on AArch64 macOS. (Previously x86_64 macOS
binary is used as fallback.)</p>
</li>
<li>
<p>Support installing native binary for <code>just</code> and
<code>sccache</code> on AArch64 Windows. (Previously x86_64 Windows
binary is used as fallback.)</p>
</li>
<li>
<p>Update <code>mdbook@latest</code> to 0.4.44.</p>
</li>
<li>
<p>Update <code>cargo-semver-checks@latest</code> to 0.39.0.</p>
</li>
</ul>
<h2>2.47.28</h2>
<p>No change on the <code>install-action</code> itself.</p>
<ul>
<li>
<p>Provide <code>install-action-manifest-schema</code> crate to access
to the <code>install-action</code> manifests from Rust code. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/657">#657</a>,
thanks <a
href="https://github.com/NobodyXu"><code>@NobodyXu</code></a>)</p>
<p>This is being considered for use to speed up
<code>cargo-binstall</code> in the future.</p>
</li>
</ul>
<h2>2.47.27</h2>
<ul>
<li>
<p>Update <code>editorconfig-checker@latest</code> to 3.2.0.</p>
</li>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.6.3.</p>
</li>
</ul>
<h2>2.47.26</h2>
<ul>
<li>Update <code>wash@latest</code> to 0.38.0.</li>
</ul>
<h2>2.47.25</h2>
<ul>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.114.</p>
</li>
<li>
<p>Update <code>git-cliff@latest</code> to 2.8.0.</p>
</li>
</ul>
<h2>2.47.24</h2>
<ul>
<li>
<p>Update <code>syft@latest</code> to 1.19.0.</p>
</li>
<li>
<p>Update <code>just@latest</code> to 1.39.0.</p>
</li>
</ul>
<h2>2.47.23</h2>
<ul>
<li>Update <code>wasmtime@latest</code> to 29.0.1.</li>
</ul>
<h2>2.47.22</h2>
<ul>
<li>Update <code>trunk@latest</code> to 0.21.7.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<h2>[2.47.30] - 2025-01-28</h2>
<ul>
<li>
<p>Support <code>cargo-cyclonedx</code> on x86_64 Linux (musl).</p>
</li>
<li>
<p>Support installing native binary for <code>cargo-cyclonedx</code> on
AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p>
</li>
<li>
<p>Update <code>cargo-cyclonedx@latest</code> to 0.5.7.</p>
</li>
</ul>
<h2>[2.47.29] - 2025-01-28</h2>
<ul>
<li>
<p>Support <code>cargo-semver-checks</code> on AArch64 Linux.</p>
</li>
<li>
<p>Support <code>cargo-zigbuild</code> on x86_64 macOS.</p>
</li>
<li>
<p>Support installing native binary for <code>mdbook</code> and
<code>shellcheck</code> on AArch64 macOS. (Previously x86_64 macOS
binary is used as fallback.)</p>
</li>
<li>
<p>Support installing native binary for <code>just</code> and
<code>sccache</code> on AArch64 Windows. (Previously x86_64 Windows
binary is used as fallback.)</p>
</li>
<li>
<p>Update <code>mdbook@latest</code> to 0.4.44.</p>
</li>
<li>
<p>Update <code>cargo-semver-checks@latest</code> to 0.39.0.</p>
</li>
</ul>
<h2>[2.47.28] - 2025-01-28</h2>
<p>No change on the <code>install-action</code> itself.</p>
<ul>
<li>
<p>Provide <code>install-action-manifest-schema</code> crate to access
to the <code>install-action</code> manifests from Rust code. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/657">#657</a>,
thanks <a
href="https://github.com/NobodyXu"><code>@NobodyXu</code></a>)</p>
<p>This is being considered for use to speed up
<code>cargo-binstall</code> in the future.</p>
</li>
</ul>
<h2>[2.47.27] - 2025-01-28</h2>
<ul>
<li>
<p>Update <code>editorconfig-checker@latest</code> to 3.2.0.</p>
</li>
<li>
<p>Update <code>cargo-lambda@latest</code> to 1.6.3.</p>
</li>
</ul>
<h2>[2.47.26] - 2025-01-27</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="afbe5c1715"><code>afbe5c1</code></a>
Release 2.47.30</li>
<li><a
href="6fde044d27"><code>6fde044</code></a>
codegen: Address cargo-cyclonedx 0.5.1 asset change</li>
<li><a
href="544f616845"><code>544f616</code></a>
ci: Remove not triggered manifest_sync workflow</li>
<li><a
href="3b94b1e00e"><code>3b94b1e</code></a>
Release 2.47.29</li>
<li><a
href="f07d824129"><code>f07d824</code></a>
Update .gitattributes</li>
<li><a
href="fc5961fb83"><code>fc5961f</code></a>
codegen: cargo-zigbuild's macOS binary is universal binary</li>
<li><a
href="df3b728223"><code>df3b728</code></a>
codegen: Sort platform</li>
<li><a
href="58e7e8a24b"><code>58e7e8a</code></a>
codegen: Mark go's static-linked linux binaries as musl</li>
<li><a
href="1d9ff62a86"><code>1d9ff62</code></a>
codegen: shellcheck 0.10.0+ provides AArch64 macOS binary</li>
<li><a
href="85a4a5fd84"><code>85a4a5f</code></a>
codegen: sccache 0.8.2+ provides AArch64 Windows binary</li>
<li>Additional commits viewable in <a
href="c87777c316...afbe5c1715">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>
We try to unit test on each major platform we support in CI to reduce
the possibility a specific OS has issues with our unit tests. Now that
macos-15 is available in GitHub CI, it would be a good idea to add it to
the mix.
To improve supply-chain security, reference all GitHub actions using the
hash of the released tag. GitHub recommends to do this for third-party
actions
(https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions).
In order to make our CI more deterministic, I opted to do it for all our
actions. This means any change to our workflow configuration requires a
source code change and thus passing CI on our end.
Dependabot will automatically issue PRs for these actions and update the
comment with the new version next to them.
Resolves: #2497.
Currently, the Gateway logs all errors that happen when the event-loop
exits on ERROR level. This creates Sentry alerts for things like
"Unauthorized" errors or "404 Not found".
That isn't useful to us. To mitigate this, we polish the code a bit to
only log an ERROR when we actually fail to setup something during
startup (like the TUN device). In all other cases, we now log a more
user-friendly message on INFO but still exit with the appropriate exit
code (0 on CTRL+C, 1 on any other error).
## Context
The Gateway implements a stateful NAT that translates the destination IP
and source protocol of every packet that targets a DNS resource IP. This
is necessary because the IPs for DNS resources are generated on the
client without actually performing a DNS lookup, instead it always
generates 4 IPv4 and 4 IPv6 addresses. On the Gateway, these IPs are
then assigned in a round-robin fashion to the actual IPs that the domain
resolves to, necessitating a NAT64/46 translation in case a domain only
resolves to IPs of one family.
A domain may resolve to a set of IPs but not all of these IPs may be
routable. Whilst an arguably poor practise of the domain administrator,
routing problems can occur for all kinds of reasons and are well handled
on the wider Internet.
When an IP packet cannot be routed further, the current routing node
generates an ICMP error describing the routing failure and sends it back
to the original sender. ICMP is a layer 4 protocol itself, same as TCP
and UDP. As such, sending out a UDP packet may result in receiving an
ICMP response. In order to allow the sender to learn, which packet
failed to route, the ICMP error embeds parts of the original packet in
its payload [0] [1].
The Gateway's NAT table uses parts of the layer 4 protocol as part of
its key; the UDP and TCP source port and the ICMP echo request
identifier (further referred to as "source protocol"). An ICMP error
message doesn't have any of these, meaning the lookup in the NAT table
currently fails and the ICMP error is silently dropped.
A lot of software implements a happy-eyeballs approach and probs for
IPv6 and IPv4 connectivity simulataneously. The absence of the ICMP
errors confuses that algorithm as it detects the packet loss and starts
retransmits instead of giving up.
## Solution
Upon receiving an ICMP error on the Gateway, we now extract the
partially embedded packet in the ICMP error payload. We use the
destination IP and source protocol of _that_ packet for the lookup in
the NAT table. This returns us the original (client-assigned)
destination IP and source protocol. In order for the Gateway's NAT to be
transparent, we need to patch the packet embedded in the ICMP error to
use the original destination and source protocol. We also have to
account for the fact that the original packet may have been translated
with NAT64/46 and translate it back. Finally, we generate an ICMP error
with the appropriate code and embed the patched packet in its payload.
## Test implementation
To test that this works for all kind of combinations, we extend
`tunnel_test` to sample a list of unreachable IPs from all IPs sampled
for DNS resources. Upon receiving a packet for one of these IPs, the
Gateway will send an ICMP error back instead of invoking its regular
echo reply logic. On the client-side, upon receiving an ICMP error, we
extract the originally failed packet from the body and treat it as a
successful response.
This may seem a bit hacky at first but is actually how operating systems
would treat ICMP errors as well. For example, a `TcpSocket::connect`
call (triggering a TCP SYN packet) may fail with an IO error if we
receive an ICMP error packet. Thus, in a way, the original packet got
answered, just not with what we expected.
In addition, by treating these ICMP errors as responses to the original
packet, we automatically perform other assertions on them, like ensuring
that they come from the right IP address, that there are no unexpected
packets etc.
## Test alternatives
It is tricky to solve this in other ways in the test suite because at
the time of generating a packet for a DNS resource, we don't know the
actual IP that is being targeted by a certain proxy IP unless we'd start
reimplementing the round-robin algorithm employed by the Gateway. To
"test" the transparency of the NAT, we'd like to avoid knowing about
these implementation details in the test.
## Future work
In this PR, we currently only deal with "Destination Unreachable" ICMP
errors. There are other ICMP messages such as ICMPv6's `PacketTooBig` or
`ParameterProblem`. We should eventually handle these as well. They are
being deferred because translating those between the different IP
versions is only partially implemented and would thus require more work.
The most pressing need is to translate destination unreachable errors to
enable happy-eyeballs algorithms to work correctly.
Resolves: #5614.
Resolves: #6371.
[0]: https://www.rfc-editor.org/rfc/rfc792
[1]: https://www.rfc-editor.org/rfc/rfc4443#section-3.1
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.
This ensure that we run prettier across all supported filetypes to check
for any formatting / style inconsistencies. Previously, it was only run
for files in the website/ directory using a deprecated pre-commit
plugin.
The benefit to keeping this in our pre-commit config is that devs can
optionally run these checks locally with `pre-commit run --config
.github/pre-commit-config.yaml`.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Closes#7171
If the assets aren't bundled, Tauri will warn about it in `tracing`,
that will get sent to Sentry, and then it will be interpreted as an
error.
Timeline to prove that this fixes the false positive error in Sentry,
all times UTC on October 29th:
- 21:01:26 - Most recent events in Sentry as of 21:20:19
- 21:11:09 - Restarted CI while CD is quiet
- 21:14:01 - First smoke test begins
- 21:19:39 - Last smoke test ends
If edns0 doesn't work correctly DNS servers might respond with messages
bigger than our maximum udp size.
In that case we need to truncate those messages when forwarding the
respond back to the interface and expect the OS to retry with TCP.
Otherwise we aren't able to allocate a packet big enough for this.
Fixes#7121
---------
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Closes#4883
Refs #7005
Adds support for Ubuntu 24.04, drops support for Ubuntu 20.04
Known issues:
- On Ubuntu 22.04, sometimes GNOME shows the wrong tray icon
- On Ubuntu 24.04, the first time you open the tray menu, GNOME takes a
long time to open the menu.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Currently, tests only send ICMP packets back and forth, to expand our
coverage and later on permit us cover filters and resource picking this
PR implements sending UDP and TCP packets as part of that logic too.
To make this PR simpler in this stage TCP packets don't track an actual
TCP connection, just that they are forwarded back and forth, this will
be fixed in a future PR by emulating TCP sockets.
We also unify how we handle CIDR/DNS/Non Resources to reduce the number
of transitions.
Fixes#7003
---------
Signed-off-by: Gabi <gabrielalejandro7@gmail.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Refs #6927
This PR creates a GTK+ event loop, a blank window, and the tray menu. It
connects to the IPC service, you can sign in and everything, but the
About window, Settings window, and Welcome window aren't implemented.
We build a deb package in CI but it isn't pushed to the draft releases
in CD yet.
Pros over Iced:
- More mature
- Easy integration with `tray-icon`
- Small binaries (< 1 MB for this example)
Cons:
- GTK 3.x is abandoned as of March. GTK 4 isn't packaged for Ubuntu
20.04.
- Widgets might be hard to use
- Hard to set up on Windows, only using this for Linux for now
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Our tests are pretty fast now, meaning we can afford running more
permutations. This makes it less likely to encounter flakes in the
"coverage" tests where we grep for certain log lines to ensure that the
tests hit certain code paths.
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Refs #6138
Sentry is always enabled for now. In the near future we'll make it
opt-out per device and opt-in per org (see #6138 for details)
- Replaces the `crash_handling` module
- Catches panics in GUI process, tunnel daemon, and Headless Client
- Added a couple "breadcrumbs" to play with that feature
- User ID is not set yet
- Environment is set to the API URL, e.g. `wss://api.firezone.dev`
- Reports panics from the connlib async task
- Release should be automatically pulled from the Cargo version which we
automatically set in the version Makefile
Example screenshot of sentry.io with a caught panic:
<img width="861" alt="image"
src="https://github.com/user-attachments/assets/c5188d86-10d0-4d94-b503-3fba51a21a90">
In the past, we struggled a lot of the reproducibility of `tunnel_test`
failures because our input state and transition strategies were not
deterministic. In the end, we found out that it was due to the iteration
order of `HashMap`s.
To make sure this doesn't regress, we added a check to CI at the time
that compares the debug output of all regression seeds against a 2nd run
and ensures they are the same. That is overall a bit wonky.
We can do better by simple sampling a value from the strategy twice from
a test runner with the same seed. If the strategy is deterministic,
those need to be the same. We still rely on the debug output being
identical because:
a. Deriving `PartialEq` on everything is somewhat cumbersome
b. We actually care about the iteration order which a fancy `PartialEq`
implementation might ignore
This happens because the smoke test is stubbed out for release builds,
so any `use` statements that are only used in the smoke tests will cause
a warning in `--release` builds, including when we make release bundles.
Currently, we have two structs for representing IP packets: `IpPacket`
and `MutableIpPacket`. As the name suggests, they mostly differ in
mutability. This design was originally inspired by the `pnet_packet`
crate which we based our `IpPacket` on. With subsequent iterations, we
added more and more functionality onto our `IpPacket`, like NAT64 &
NAT46 translation. As a result of that, the `MutableIpPacket` is no
longer directly based on `pnet_packet` but instead just keeps an
internal buffer.
This duplication can be resolved by merging the two structs into a
single `IpPacket`. We do this by first replacing all usages of
`IpPacket` with `MutableIpPacket`, deleting `IpPacket` and renaming
`MutableIpPacket` to `IpPacket`. The final design now has different
`self`-receivers: Some functions take `&self`, some `&mut self` and some
consume the packet using `self`.
This results in a more ergonomic usage of `IpPacket` across the codebase
and deletes a fair bit of code. It also takes us one step closer towards
using `etherparse` for all our IP packet interaction-needs. Lastly, I am
currently exploring a performance-optimisation idea that stack-allocates
all IP packets and for that, the current split between `IpPacket` and
`MutableIpPacket` does not really work.
Related: #6366.
This PR introduces the `etherparse` dependency for parsing and
generating IP packets.
Using `etherparse`, we can implement the NAT46 & NAT64 implementations
for the gateway more elegantly because it allows us to parse the IP and
protocol headers into a static and much richer representation. The
conversion to the IPv4/IPv6 equivalent is then just a question of
transforming one data structure into another and writing it to the
correct place in the buffer.
We extract this functionality into dedicated `nat64` and `nat46`
modules.
Furthermore, we implement the various functions in `ip_packet::make`
using `etherparse` too. Following that, we also overhaul the NAT
translation tests that we have in `ip_packet::proptests`. Those now use
the more low-level `consume_to_ipX` APIs which makes the tests more
ergonomic to write.
In the future, we should upstream `Ipv4HeaderSliceMut` and
`Ipv6HeaderSliceMut` to `etherparse`.
Moving all of this functionality to `etherparse` will make it easier to
write tests that involve more IP packets as well as customise the
behaviour of our NAT.
Related: #5614.
Related: #6371.
Related: #6353.
`install-action` uses `cargo-binstall` as a fallback. That binary
contacts GitHub which may run into rate-limit without being
authenticated. In that case, we will install manually which takes very
long.
Resolves: #6374.
It happened in the past that we screwed up the `preconditions` of the
state machine test such that no more transitions were sampled that
actually send packets. To protect against this, we use the newly
introduced logs and grep for certain transitions.
In the future, we can consider emitting a more structured output, like
writing all testcases to a DB and run more complex queries against it to
ensure that certain cases are covered.
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>
Currently, `tunnel_test` executes all actions within the same `Instant`,
i.e. time is never advanced by itself. The difficulty with advancing
time compared to other actions like sending packets is that all
time-related actions "overlap". In other words, all timers within
connlib advance at the same time. This makes it difficult to model the
expected behaviour after a certain amount of time has passed as we'd
effectively need to model all timers and their relation to particular
actions (like resending of connection intents or STUN requests).
Instead of only advancing time by itself, we can model some aspect of it
by introducing latency on network messages. This allows us to define a
range of an "acceptable" network latency within everything is expected
to work.
Whilst this doesn't cover all failure cases, it gives us a solid
foundation of parameters within which we should not expect any
operational problems.
This version was a few months old and started throwing errors about
features that stabilized since then.
e.g.
https://github.com/firezone/firezone/actions/runs/10011089436/job/27673759249
```
error[E0658]: use of unstable library feature 'proc_macro_byte_character'
--> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.86/src/wrapper.rs:871:21
|
871 | proc_macro::Literal::byte_character(byte)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #115268 <https://github.com/rust-lang/rust/issues/115268> for more information
= help: add `#![feature(proc_macro_byte_character)]` to the crate attributes to enable
= note: this compiler was built on 2024-03-25; consider upgrading it if it is out of date
error[E0658]: use of unstable library feature 'proc_macro_c_str_literals'
--> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.86/src/wrapper.rs:898:21
|
898 | proc_macro::Literal::c_string(string)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #119750 <https://github.com/rust-lang/rust/issues/119750> for more information
= help: add `#![feature(proc_macro_c_str_literals)]` to the crate attributes to enable
= note: this compiler was built on 2024-03-25; consider upgrading it if it is out of date
For more information about this error, try `rustc --explain E0658`.
error: could not compile `proc-macro2` (lib) due to 2 previous errors
```
