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
```
Our Rust CI runs various jobs in different configurations of packages
and / or features. Currently, only the clippy job denies warnings which
makes it possible that some code still generates warnings under
particular configurations.
To ensure we always fail on warnings, we set a global env var to deny
warnings for all Rust CI jobs.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Closes#5810
```[tasklist]
### Tasks
- [x] Try not to set the icon every time we change Resources
- [x] Get production icons
- [x] Add changelog comment
- [x] Add CI stress test that sets the icon 10,000 times
- [x] Open for review
- [x] Repair changelog
- [ ] Merge
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Closes#5601
It looks like we can hit 100+ Mbps in theory. This covers Wintun, Tokio,
and Windows OS overhead. It doesn't cover the cryptography or anything
in connlib itself.
The code is kinda messy but I'm not sure how to clean it up so I'll just
leave it for review.
This test should fail if there's any regressions in #5598.
It fails if any packet is dropped or if the speed is under 100 Mbps
```[tasklist]
### Tasks
- [x] Use `ip_packet::make`
- [x] Switch to `cargo bench`
- [x] Extract windows ARM PR
- [x] Clean up wintun.dll install code
- [x] Re-request review
```
```[tasklist]
### Tasks
- [x] Check the GUI saves its settings file
- [x] Check the IPC service writes the device ID to disk
- [x] Check the GUI writes a log file (skipped - we already check if the exported zip has any files in it)
- [x] Run the crash file through `minidump-stackwalk`
- [x] Reach feature parity with the original smoke tests
- [x] Ready for review
- [x] Finish #5452
- [ ] Start on #5453
```
Currently, the smoke tests rebuild the `dump_syms` and
`minidump-stackwalk` tools from scratch every time which is slow,
especially on Windows.
We can speed this up by utilising the `taiki-e/install-action` GitHub
action which discovers and downloads the latest binary releases of those
projects and installs them into $PATH.
I think those binaries might also be cached as part of the Rust cache
action (https://github.com/Swatinem/rust-cache) so the visible speed-up
is only within a few seconds and comes from the binaries not being
re-built inside the script.
Caching those binaries on Github still requires us to build them at
least once and also rebuild them in case the cache gets invalidated.
Hence I still think this is a good idea on its own.
When the `tunnel_test` fails, it generates a lot of output because it
keeps printing the backtrace over and over. This makes it difficult to
access the input seed to the test. Copying this seed into a local
environment is the first step in debugging this, at which point the
backtrace can be enabled locally.
We also disable the `verbose: 1` config option. Users can always set
that using the `PROPTEST_VERBOSE` env variable.
With an increased number of tests that make use of `proptest`, executing
`cargo test` (almost 6 minutes on `main` currently:
https://github.com/firezone/firezone/actions/runs/9278428694/job/25529425068#step:5:1407).
By compiling them with optimisations, we can drastically cut down the
execution time with only little penality in compilation speed as those
should be cached in CI.
This is similar to #4097 and #4585 but for the entire `ClientState` and
`GatewayState`. We also do it in the context of a property-based test
with the vision that we can deterministically explore a large space of
state transitions and see where our main property breaks: Being able to
send an ICMP packet from the client to the gateway.
In other words, we now correctly pass all the `Transmit`s back and forth
between the components as if they would receive it from the network. Due
to the nature of property-based tests, this already exercises a very
large input space. For example, if the client does not have an IPv6
socket and the gateway doesn't have an IPv4 socket, this test already
checks whether we then correctly fall back to using a relay (because the
allocation we make on the relay is the only network path where the STUN
requests pass through).
What this does not (yet) do is set up a proper network topology. The
`dispatch_transmit` function will happily "route" a `Transmit` from e.g.
the client to the gateway even if they are in different subnets. In
other words, these tests assume that the actual network itself works and
we can exchange UDP packets between the components.
For now, we only send ICMPs to CIDR resources. As a next step, we can
extend this to DNS resources by sending DNS queries for our DNS
resources and then sending an ICMP to the resolved IP.
It typically takes about 1 minute to run in CI. We don't have any leads
on fixing this issue, and it may be a regression in a recent release of
WebView2. https://github.com/firezone/firezone/pull/4935
This will fix an issue with `linux-group` and `token-path` that happens
when I try to split up the binaries.
```[tasklist]
### Before merging
- [x] Fix linux-group. That stub-ipc-client command doesn't even exist anymore
```
```[tasklist]
# Before merging
- [x] Remove file extension `.txt`
- [x] Wait for `linux-group` test to go green on `main` (#4692)
- [x] *all* compatibility tests must be green on this branch
```
Closes#4664Closes#4665
~~The compatibility tests are expected to fail until the next release is
cut, for the same reasons as in #4686~~
The compatibility test must be handled somehow, otherwise it'll turn
main red.
`linux-group` was moved out of integration / compatibility testing, but
the DNS tests do need the whole Docker + portal setup, so that one can't
move.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Closes#4669
This should stop the problem of `linux-group` failing because of trying
to test an older release that doesn't have the right CLI features
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
(After GA)
This adds a unit test for the Unix domain sockets that I intend to use
for process splitting on Linux.
The length-prefixed encoding and decoding are copied from `subzone`, but
most of that code will not be re-used since it's Windows-specific and
also specific to a Chromium-like process model, which won't work for
Firezone.
This catches two of the mutants, according to `cargo-mutants`.
~~Unfortunately since `cargo test` runs in one process, it's
all-or-nothing for sudo, this will run all unit tests as sudo.~~
(This explanation is not exactly correct, `cargo test` does run _a_
subprocess, but still, there is no way to request sudo or non-sudo
runners for specific tests, since it's just an environment variable, and
since many tests run in parallel in different threads of the same
process.)
Here it is passing in Linux:
https://github.com/firezone/firezone/actions/runs/8382799272/job/22957555987#step:5:3160
And Windows:
https://github.com/firezone/firezone/actions/runs/8382799272/job/22957558003#step:5:1006
```[tasklist]
### Before merging
- [x] Try `#[ignore]` attribute
- [x] Fail gracefully if `sudo` isn't available
```
Closes#3699 if successful
Ref #3972
I don't understand why it started working. There's at least 3
possibilities:
- Some unrelated change in the last few weeks fixed it (Maybe bumping
Tauri to 1.6.1? https://github.com/firezone/firezone/pull/3881)
- It was a bug in the Github CI runner image that they fixed
- It's an awful race condition and adding `tracing::debug!` fixed it
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
