Closes#3815
Changes that are breaking (but these aren't in production so it should
be okay)
- Windows, renaming `device_id.json` to `firezone-id.json` to match the
rest of the code
- Linux GUI, storing the firezone-id under `/var/lib` instead of under
`$HOME`
- Linux GUI, bails out if not run with `sudo --preserve-env` by
detecting `$HOME == root` or `$USER != root`
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Refs #3230
It looks like we need to sign the internal exe before it gets bundled
too. We can use `beforeBundleCommand` to do so.
Soon, Tauri should have native support for this exact scenario:
https://github.com/tauri-apps/tauri/pull/8718
Builds off #3905 and uses the GH actions cache for tauri builds in order
to get around the `crate-type` problem sccache has with Tauri apps.
Fixes#3456
- Auto-labels PRs based on PR title so that they're automatically
categorized when generating the Changelog.
- Enforce ConventionalCommit-style PR titles so they can be easily
categorized in the changelog
Reverts firezone/firezone#3897
The gateway binary published on the releases page still isn't updated
with this fix, so going to revert to implement a more long-term
solution.
Bumps
[lycheeverse/lychee-action](https://github.com/lycheeverse/lychee-action)
from 1.9.0 to 1.9.3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/lycheeverse/lychee-action/releases">lycheeverse/lychee-action's
releases</a>.</em></p>
<blockquote>
<h2>Version 1.9.3</h2>
<h2>What's Changed</h2>
<ul>
<li>Bugfix: Pass custom <code>token</code> as input argument to action
by <a href="https://github.com/mre"><code>@mre</code></a> in <a
href="https://redirect.github.com/lycheeverse/lychee-action/pull/222">lycheeverse/lychee-action#222</a>
Previously, the name of the token was incorrect, leading to no token
being used if the user specified <code>with: [token: ...]</code>.
Thanks to <a href="https://github.com/tobon4"><code>@tobon4</code></a>
for pointing this out.</li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/lycheeverse/lychee-action/compare/v1...v1.9.3">https://github.com/lycheeverse/lychee-action/compare/v1...v1.9.3</a></p>
<h2>Version 1.9.2</h2>
<h2>What's Changed</h2>
<ul>
<li>Bump actions/cache from 3 to 4 by <a
href="https://github.com/dependabot"><code>@dependabot</code></a> in <a
href="https://redirect.github.com/lycheeverse/lychee-action/pull/221">lycheeverse/lychee-action#221</a></li>
<li>Bump peter-evans/create-issue-from-file from 4 to 5 by <a
href="https://github.com/dependabot"><code>@dependabot</code></a> in <a
href="https://redirect.github.com/lycheeverse/lychee-action/pull/223">lycheeverse/lychee-action#223</a></li>
<li>Bump to lychee 0.14.2 in <a
href="eeb9cb63fe</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/lycheeverse/lychee-action/compare/v1...v1.9.2">https://github.com/lycheeverse/lychee-action/compare/v1...v1.9.2</a></p>
<h2>Version 1.9.1</h2>
<p>This is a hotfix release which restores the behavior of the
<code>accept</code> config parameter.
Integers are accepted again as status codes.</p>
<pre lang="toml"><code>accept = [200, 201, 202, 203, 429]
</code></pre>
<p>is equivalent to</p>
<pre lang="toml"><code>accept = ["200..=203", 429]
</code></pre>
<p>Integers and strings (e.g. for ranges) can be mixed.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="c053181aa0"><code>c053181</code></a>
Pass custom <code>token</code> as input argument to action (<a
href="https://redirect.github.com/lycheeverse/lychee-action/issues/222">#222</a>)</li>
<li><a
href="eeb9cb63fe"><code>eeb9cb6</code></a>
Bump to lychee 0.14.2</li>
<li><a
href="0fa791a2a1"><code>0fa791a</code></a>
Bump peter-evans/create-issue-from-file from 4 to 5 (<a
href="https://redirect.github.com/lycheeverse/lychee-action/issues/223">#223</a>)</li>
<li><a
href="8c9a282bef"><code>8c9a282</code></a>
Bump actions/cache from 3 to 4 (<a
href="https://redirect.github.com/lycheeverse/lychee-action/issues/221">#221</a>)</li>
<li><a
href="c3089c702f"><code>c3089c7</code></a>
Bump to lychee 0.14.1</li>
<li><a
href="fdea703267"><code>fdea703</code></a>
Update secure git hash for 1.9.0</li>
<li>See full diff in <a
href="https://github.com/lycheeverse/lychee-action/compare/v1.9.0...v1.9.3">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 message is sent by the some of the broadcasters and it was
resulting in a process crash (on a socket that will be disconnected
anyways), but this triggered our logging alerts anyways. So we will
simply ignore them globally to suppres the noise.
Fixes various small issues, including some of the issues in #3768:
- Clicking "About" or "Settings" no longer toggles a window between
visible and hidden, it always shows and un-minimizes the window. So if
it's minimized, it won't vanish, it will appear
- Log message for vt100 failure is clearer
- The "cancel sign-in" race was coincidentally already working as
intended, but the code and comments are clarified.
- Fix the asset name used to check for auto-updates (this cannot be
end-to-end tested until we cut a new release of the clients on Github,
not just a draft release)
- Fix README to include Ubuntu instructions
With the use of `quinn-udp`, we are actually already using GRO for
reading packets from the UDP socket. Especially during a test like
iperf, it is thus very likely to read multiple packets from the same
peer in a single syscall. In that case, `stride` tells us how they are
split.
Without handling `stride` correctly, we would be feeding multiple
packets at once to boringtun which would (obviously) choke on it because
its checksum verification fails.
It turns out we can actually handle this quite nicely by returning an
`Iterator<Item = Received>` and decapsulating them one-by-one.
~~Highlights the issue hypothesized in #3666~~
This tests that restarting a Relay won't cause sustained downtime.
Sleeps have been removed as they shouldn't necessary -- removing them
will better catch race conditions.
(Waiting on #3721)
Ubuntu is headless by default and needs `xvfb` to run Tauri in CI, hence
the difference.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
This may cause conflicts with all my other PRs but it has to happen.
```[tasklist]
- [ ] Update test names in branch protection (I don't think I have perms for this)
```
This prevents duplication for different Tauri jobs like building the
release packages vs testing a debug build with mock keyring.
```[tasklist]
- [ ] Fix branch protection rules for changed tests
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
The iperf3 server sometimes hangs, or takes a while to startup.
Rather than trying to reset the iperf3 state between performance tests,
this PR refactors them so they each run in their matrix job. This
ensures each performance test will run on a separate VM, unaffected by
previous test runs to eliminate the effect any residual network buffer
state can have on a particular test.
It also makes sure the server is listening with a `healthcheck`.
So the cause of the flaky tests is that they aren't waiting long enough
for a connection to be established. Both the test in #3666 and the
`iperf` tests have a timeout of 10 seconds.
Connections _should_ be established **very quickly** in CI. However, I
have a few guesses as to why they might not be, essentially causing us
to have to wait for a timeout to re-initiate a connection request:
- Packets arrive out of order or too quickly for the WireGuard state
machine to establish a handshake.
- Too many ICE candidates gathered (the gateway has 3 interfaces)
This PR:
- Refactors the iperf tests to be a little easier to maintain
- Ensures `integration-tests` run for at least 30 seconds before timing
out
In any case, we can debug / optimize this further after snownet is
merged, which might just solve the problem completely.
This will prevent services from restarting out from under us during
tests.
Service restarts should be explicitly tested as integration tests.
Should fix#3666
Whilst debugging the performance tests in #3391, I found that we are
using a 4 year old version of `iperf` for the server. This, plus
restarting the server inbetween the performance runs resulted in flaky
tests. I am not sure how we arrived at #3303 but
[this](https://github.com/firezone/firezone/actions/runs/7926579022?pr=3391)
CI run succeeded with a big matrix using the newer iperf server and
without the restarts.
Attempt at cleaning a couple things I missed in code review.
The old httpbin resource wasn't being used anyhow, so I just deduped
them and updated things in a couple other places that had drifted.
Hopefully this fixes the [flaky
CI](https://github.com/firezone/firezone/actions/runs/7918422653/job/21616835910)
Regardless of `FIREZONE_DNS_CONTROL`, always try to notify systemd that
we've started.
I had accidentally conflated the idea of running as a systemd service
with the idea of using systemd to control DNS. They're separate, but
I'll keep the service unit in here and always use `sd-notify` since it
should be harmless to use even in Alpine.
~~If `FIREZONE_DNS_CONTROL` is `systemd-resolved`, try to notify systemd
that we've finished startup and the tunnel is ready.~~
Also adds a CI test, including a systemd service file that is **not**
ready for general use.
Ready for review once it's green.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Running perf byitself should be enough to establish a connection, we
don't need to explicitly do that before.
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Only user-facing if users are using the Docker image for the Linux
client.
I split off a module for `/etc/resolv.conf` since the code and unit
tests are about 300 lines and aren't related to the rest of the
`tun_linux.rs` code.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
This improves maintenance because we can now use a regular matrix for
the integration tests and one can locally use tools like shellcheck or a
`bash-lsp` during development.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Fixes#3578Fixes#3551
The issue turned out to be a bunk Repository. Upon unraveling that ball
of yarn, I decided to clean up the Tunnel implementation altogether. It
uses the existing tunnel in-memory store for pushing updates to a
connected SessionActivity.
This PR includes many bug fixes as well.
