Rust 1.91 has been released and brings with it a few new lints that we
need to tidy up. In addition, it also stabilizes `BTreeMap::extract_if`:
A really nifty std-lib function that allows us to conditionally take
elements from a map. We need that in a bunch of places.
- Removes the swift DerivedData cache. This was added to attempt to
speed up the Swift builds in CI but in reality, those are already fast
and the cache did not speed them up.
- Removes the runner.os/arch specifier from the Webview installer cache
key. The binary download is hardcoded for a specific windows version /
arch already so the cache key just adds unneeded complexity.
These caches are getting saved on PR runs which consumes excess GHA
cache storage.
The headless client image we ship doesn't have systemd-resolved. By
default, if you try to run it without setting the `FIREZONE_DNS_CONTROL`
var, it will exit with an unhelpful error message that is difficult to
diagnose / debug for anyone unfamiliar to the inner workings of the
headless client:
```
Error: I/O error: No such file or directory (os error 2)
Caused by:
No such file or directory (os error 2)
Stack backtrace:
0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
1: firezone_bin_shared::network_changes::imp::Worker::new_dbus::{{closure}}
2: firezone_headless_client::main::{{closure}}
3: tokio::runtime::runtime::Runtime::block_on
4: firezone_headless_client::main
5: std::sys::backtrace::__rust_begin_short_backtrace
6: std::rt::lang_start::{{closure}}
7: main
```
To fix this, we set `FIREZONE_DNS_CONTROL=etc-resolv-conf` for the user
inside our headless-client image.
---------
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
In Docker environments, applying iptables rules to filter
container-container traffic on the Docker bridged network is not
reliable, leading to direct connections being established in our relayed
tests. To fix this, we insert the rules directly from the client
container itself.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
We don't ever use the `dev` stage within our Rust Dockerfile that
actually builds the binaries within the container. In CI, we build the
binaries on the host and then copy them in. During local development, I
always do the same because it is much faster to iterate that way.
Long story short: We don't need this stage within our Dockerfile and it
causes confusion when people try to use `docker compose build`. If
somebody really wanted to do that, they need to follow the instructions
in the Dockerfile and build the binary first.
Related: #8687
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Bumps the tauri group in /rust with 1 update:
[tauri](https://github.com/tauri-apps/tauri).
Updates `tauri` from 2.2.3 to 2.2.5
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tauri-apps/tauri/releases">tauri's
releases</a>.</em></p>
<blockquote>
<h2>tauri-cli v2.2.5</h2>
<!-- raw HTML omitted -->
<pre><code>Updating git repository
`https://github.com/tauri-apps/schemars.git`
Updating crates.io index
Locking 1053 packages to latest compatible versions
Adding apple-codesign v0.27.0 (available: v0.29.0)
Adding axum v0.7.9 (available: v0.8.1)
Adding colored v2.2.0 (available: v3.0.0)
Adding dirs v5.0.1 (available: v6.0.0)
Adding html5ever v0.26.0 (available: v0.29.0)
Adding itertools v0.13.0 (available: v0.14.0)
Adding minisign v0.7.3 (available: v0.7.9)
Adding oxc_allocator v0.36.0 (available: v0.47.0)
Adding oxc_ast v0.36.0 (available: v0.47.0)
Adding oxc_parser v0.36.0 (available: v0.47.0)
Adding oxc_span v0.36.0 (available: v0.47.0)
Adding proc-macro-crate v2.0.0 (available: v2.0.2)
Adding serialize-to-javascript v0.1.1 (available: v0.1.2)
Adding serialize-to-javascript-impl v0.1.1 (available: v0.1.2)
Adding tauri-utils v1.6.0 (available: v1.6.2)
Adding tiny_http v0.11.0 (available: v0.12.0)
Adding webview2-com v0.34.0 (available: v0.35.0)
Adding windows v0.58.0 (available: v0.59.0)
Adding x509-certificate v0.23.1 (available: v0.24.0)
Fetching advisory database from
`https://github.com/RustSec/advisory-db.git`
Loaded 724 security advisories (from /home/runner/.cargo/advisory-db)
Updating crates.io index
Scanning Cargo.lock for vulnerabilities (1078 crate dependencies)
Crate: atk
Version: 0.18.2
Warning: unmaintained
Title: gtk-rs GTK3 bindings - no longer maintained
Date: 2024-03-04
ID: RUSTSEC-2024-0413
URL: https://rustsec.org/advisories/RUSTSEC-2024-0413
Dependency tree:
atk 0.18.2
└── gtk 0.18.2
├── wry 0.48.1
│ └── tauri-runtime-wry 2.3.0
│ └── tauri 2.2.3
│ ├── tauri-plugin-sample 0.1.0
│ │ └── api 0.1.0
│ ├── tauri-plugin-log 2.2.0
│ │ └── api 0.1.0
│ ├── tauri-file-associations-demo 0.1.0
│ ├── tauri 2.2.3
</tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="5a3647bdfe"><code>5a3647b</code></a>
Apply Version Updates From Current Changes (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12515">#12515</a>)</li>
<li><a
href="477e9c0496"><code>477e9c0</code></a>
fix(core): Use safe_block_on in mobile proxy (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12514">#12514</a>)</li>
<li><a
href="82d634f4a9"><code>82d634f</code></a>
Apply Version Updates From Current Changes (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12512">#12512</a>)</li>
<li><a
href="8e9134c4a2"><code>8e9134c</code></a>
fix(cli): Apply --bins flag on build instead of dev (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12511">#12511</a>)</li>
<li><a
href="dc1997b77d"><code>dc1997b</code></a>
apply version updates (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12439">#12439</a>)</li>
<li><a
href="1a86974aa3"><code>1a86974</code></a>
fix(cli): let xcode handle building for <code>ios build --open</code>
(<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12406">#12406</a>)</li>
<li><a
href="fb294af8e3"><code>fb294af</code></a>
fix(tauri-driver): Parse ms:edgeOptions separately (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12383">#12383</a>)</li>
<li><a
href="46c7b16111"><code>46c7b16</code></a>
ci(renovate): Disable oxc_ PRs</li>
<li><a
href="9dac2863af"><code>9dac286</code></a>
fix(bundler): Don't self-sign dmg (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12323">#12323</a>)</li>
<li><a
href="9a9d1205b0"><code>9a9d120</code></a>
chore(deps): update dependency rollup to v4.32.0 (dev) (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12502">#12502</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/tauri-apps/tauri/compare/tauri-v2.2.3...tauri-v2.2.5">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
#7808 introduced a minor bug that prevented the rust Docker images from
building locally, in `debug` builds. Adding `openssl-dev` to the
builder's container fixes the issue.
```
cargo:warning=Could not find directory of OpenSSL installation, and this `-sys` crate cannot proceed without this knowledge. If OpenSSL is installed and this crate had trouble finding it, you can set the `OPENSSL_DIR` environment variable for the compilation process. See stderr section below for further information.
```
Rust 1.83 comes with a bunch of new lints for elidible lifetimes. Those
also trigger in the generated code of `derivative`. That crate is
actually unmaintained so we replace our usages of it with `derive_more`.
When `snownet` was first being developed, these tests ensured that
hole-punching as well as connectivity via a relayed works correctly. We
have since added extensive tests that ensure connectivity works in many
scenarios via `tunnel_test`. `tunnel_test` does not (yet) have a
simulated NAT so hole-punching itself is not covered by that.
UDP hole-punching is shockingly trivial though because all you need to
do is send UDP packets to the same socket that the other party is
sending from. This isn't done by our own code but rather by str0m's
implement of ICE (as long as we add the correct candidates).
The `snownet-tests` themselves are quite fragile because they need to
set up their own event loop and manually construct an IP packet. They
haven't caught a single bug to my knowledge so I am proposing to delete
them for ease of maintenance.
For example, in
https://github.com/firezone/firezone/actions/runs/10449965474/job/28948590058?pr=6335
the tests fail because we no longer directly force a handshake when the
connection is established. This is unnecessary now because the buffered
intent packet will directly force a handshake from the client to the
gateway. Yet, `snownet-tests` event loop would need adjusting to also do
that.
Without masquerading, packets sent by the gateway through the TUN
interface use the wrong source address (the TUN device's address)
instead of the gateway's actual network interface.
We set this env variable in all our uses of the gateway, thus we might
as well remove it and always perform unconditionally.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Considered using Elixir and Rust to write the tests.
For Elixir, `wallaby` doesn't seem to have a way to attach to an
existing `chromium` instance, launching it each time, which makes it
hard to coordinate with the relay restart.
For Rust we considered `thirtyfour` which would be very nice since we
could test both firefox and chrome but each time it connects to the
instance it launches a new session making it hard to test the DNS cache
behavior.
We also considered `chrome_headless` for Rust it needs a small patch to
prevent it from closing the browser after `Drop` but it still presents a
problem, since it has no easy way to retrieve if loading a page has
succeeded. There are some workarounds such as retrieving the title that
we could have used but after some testing they are quite finnicky and we
don't want that for CI.
So I ended up settling for TypeScript but I'm open to other options, or
a fix for the previous ones!
There are some modifications still incoming for this PR, around the test
name and that sleep in the middle of the test doesn't look good so I
will probably add some retries, but the gist is here, will keep it in
draft until we expect it to be passing.
So feel free to do some initial reviews.
Note: the number of lines changed is greatly exaggerated by
`package.lock`
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
As part of #4568, we are adding a 2nd relay which showed some
short-comings of the current process state assertions because they were
running outside the docker containers, thus listing all relays as soon
as there are multiple.
These customizations were from before we used `cargo cross` for all
architectures in CI.
1.77.1 has been tested to work with the following clients:
- [x] Apple
- [x] Android
- [x] Windows
- Runs release asset builds simultaneously with `deploy-staging`. Those
don't depend on each other.
- Prevents running some build workflows in CD because they're run
already in the PR and in the merge group, and the risk of semantic
conflict is negligible
- Run `release` assets in staging
- Adds `compatibility_tests`: **To successfully introduce a breaking
change in the control / data plane APIs, you must now "Merge as
Administrator"**
- Since `CI` is no longer run on `main`, caching needed to be refactored
to make sense again
- Since `CI` is no longer run on `main`, the Elixir
`migrations_and_seeds_test` had to be rewritten. This now tests
migrations using `git checkout` instead of importing `main`'s DB dump.
- Move tauri builds to its own workflow so we can trigger Linux and
Windows builds manually on an adhoc basis like we do for the Swift and
Kotlin builds
- Add a new `hotfix` workflow that will run `compatibility_tests` with
the latest published images
- Add `workflow_dispatch` to trigger `CD` manually for testing purposes
(cc @ReactorScram)
Refs #3995
I don't know much about `cargo chef` so I gave this its own PR in case
I'm doing something that'll subtly break it
I've run into this problem on some branches and not others, where it's
trying to build all the Tauri / glib stuff even though the Docker image
won't need it:
https://github.com/firezone/firezone/actions/runs/8012206575/job/21887478015#step:7:1175
This splits off the easy parts from #3605.
- Add quotes around `PHOENIX_SECURE_COOKIES` because my local
`docker-compose` considers unquoted 'false' to be a schema error - Env
vars are strings or numbers, not bools, it says
- Create `test.httpbin.docker.local` container in a new subnet so it can
be used as a DNS resource without the existing CIDR resource picking it
up
- Add resources and policies to `seeds.exs` per #3342
- Fix warning about `CONNLIB_LOG_UPLOAD_INTERVAL_SECS` not being set
- Add `resolv-conf` dep and unit tests to `firezone-tunnel` and
`firezone-linux-client`
- Impl `on_disconnect` in the Linux client with `tracing::error!`
- Add comments
```[tasklist]
- [x] (failed) Confirm that the client container actually does stop faster this way
- [x] Wait for tests to pass
- [x] Mark as ready for review
```
Currently, `firezone-connection` can only handle connections on a LAN.
Via the use of a STUN server, we can discover our public IP and attempt
to direct, hole-punched connection across multiple subnets.
Turns out #3276 was only part of the problem. After that was fixed, the
issue did turn out to be the statically-linked libc runtime. Staging was
using dynamic linking and so didn't hit the issue.
This reverts back to musl which has been tested as @AndrewDryga noted.
