Refs #3636 (This pays down some of the technical debt from Linux DNS)
Refs #4473 (This partially fulfills it)
Refs #5068 (This is needed to make `FIREZONE_DNS_CONTROL` mandatory)
As of dd6421:
- On both Linux and Windows, DNS control and IP setting (i.e.
`on_set_interface_config`) both move to the Client
- On Windows, route setting stays in `tun_windows.rs`. Route setting in
Windows requires us to know the interface index, which we don't know in
the Client code. If we could pass opaque platform-specific data between
the tunnel and the Client it would be easy.
- On Linux, route setting moves to the Client and Gateway, which
completely removes the `worker` task in `tun_linux.rs`
- Notifying systemd that we're ready moves up to the headless Client /
IPC service
```[tasklist]
### Before merging / notes
- [x] Does DNS roaming work on Linux on `main`? I don't see where it hooks up. I think I only set up DNS in `Tun::new` (Yes, the `Tun` gets recreated every time we reconfigure the device)
- [x] Fix Windows Clients
- [x] Fix Gateway
- [x] Make sure connlib doesn't get the DNS control method from the env var (will be fixed in #5068)
- [x] De-dupe consts
- [ ] ~~Add DNS control test~~ (failed)
- [ ] Smoke test Linux
- [ ] Smoke test Windows
```
When creating an echo request or reply packet using pnet it uses the
whole packet since the identifier and sequence is part of the icmp
header not the payload.
Those fields aren't accessible unless the packet is converted to an echo
request or reply because the interpretation of that header field depends
on the specific type of packet.
Currently, `tunnel_test` only sends ICMPs to CIDR resources. We also
want to test certain properties in regards to DNS resources. In
particular, we want to test:
- Given a DNS resource, can we query it for an IP?
- Can we send an ICMP packet to the resolved IP?
- Is the mapping of proxy IP to upstream IP stable?
To achieve this, we sample a list of `IpAddr` whenever we add a DNS
resource to the state. We also add the transition
`SendQueryToDnsResource`. As the name suggests, this one simulates a DNS
query coming from the system for one of our resources. We simulate A and
AAAA queries and take note of the addresses that connlib returns to us
for the queries.
Lastly, as part of `SendICMPPacketToResource`, we now may also sample
from a list of IPs that connlib gave us for a domain and send an ICMP
packet to that one.
There is one caveat in this test that I'd like to point out: At the
moment, the exact mapping of proxy IP to real IP is an implementation
detail of connlib. As a result, I don't know which proxy IP I need to
use in order to ping a particular "real" IP. This presents an issue in
the assertions: Upon the first ICMP packet, I cannot assert what the
expected destination is. Instead, I need to "remember" it. In case we
send another ICMP packet to the same resource and happen to sample the
same proxy IP, we can then assert that the mapping did not change.
Closes#5155
I keep seeing these in my debug Clients and I just want to make sure the
URL it's using is correct.
e.g.
```
2024-05-29T18:10:14.131542Z ERROR firezone_gui_client::client::gui: Error in check_for_updates error=Error in client::updates::check
Caused by:
HTTP status: 404 Not Found from update URL `https://www.firezone.dev/dl/firezone-client-gui-windows/latest/aarch64`
```
To encode that clients always have both ipv4 and ipv6 and they are the
only allowed source ips for any given client, into the type, we split
those into their specific fields in the `ClientOnGateway` struct and
update tests accordingly.
Furthermore, these will be used for the DNS refactor for ipv6-in-ipv4
and ipv4-in-ipv6 to set the source ip of outgoing packets, without
having to do additional routing or mappings. There will be more notes on
this on the corresponding PR #5049 .
---------
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This doesn't really matter for the functionality of the test because in
connlib, we don't expect the IPs to adhere to a certain range.
Nevertheless, to make output more readable, it is nicer if these IPs
match what we also see in production logs.
Currently, the gateway has a piece of functionality to ensure we only
ever route packets that actually originate from the client. This is
important because a gateway connects to multiple clients and thus -
without this check - client A could send a packet through the tunnel
that gets interpreted as traffic from client B by mangling the source IP
of their packets.
The portal assigns these source IPs when the clients sign in and passes
them to the gateway whenever a client connects. We can thus drop all
traffic on the gateway side from IPs that we don't recognise.
Currently, a client will still trigger a connection intent for an IP
packet, even if it doesn't have the tunnel's source IP set. We may want
to consider changing this behaviour in the future.
Since we expect a fixed MTU size, we can encode this in the size of the
buffers for the device, we will never read or write more than the 1280
MTU we expect.
Note that the `write_buf` needs an extra 16 bytes for the aead tag that
boringtun will copy over.
Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.116 to
1.0.117.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/serde-rs/json/releases">serde_json's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.117</h2>
<ul>
<li>Resolve unexpected_cfgs warning (<a
href="https://redirect.github.com/serde-rs/json/issues/1130">#1130</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0ae247ca63"><code>0ae247c</code></a>
Release 1.0.117</li>
<li><a
href="4517c7a2d9"><code>4517c7a</code></a>
PartialEq is not implemented between Value and 128-bit ints</li>
<li><a
href="fdf99c7c38"><code>fdf99c7</code></a>
Combine number PartialEq tests</li>
<li><a
href="b4fc2451d7"><code>b4fc245</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/json/issues/1130">#1130</a>
from serde-rs/checkcfg</li>
<li><a
href="98f1a247de"><code>98f1a24</code></a>
Resolve unexpected_cfgs warning</li>
<li>See full diff in <a
href="https://github.com/serde-rs/json/compare/v1.0.116...v1.0.117">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>
Currently, we assert on the actual IP packet that gets sent between
client and gateway in the tunnel test. This does not work with DNS
resources because - unless we model _how_ connlib assigns IPs for DNS
resources - we don't know what the destination IP of the resource is
that we are about to ping.
From an applications PoV, it doesn't matter, what the IP is. Thus, it is
better to write an assertion closer to what the application expects:
- A received ICMP reply should come from the IP that we pinged.
- The ICMP packet emitted on the gateway should target the actual IP of
the DNS resource.
Extracted out of #5083.
An `IpPacket` may contain an ICMP or ICMPv6 packet. To extract metadata
like the sequence number of identifier from it, we need to be able to
parse an `IpPacket`'s payload into the appropriate packets.
Extracted out of #5083.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Whilst initially convenient, the `prop_oneof` macro is convenient when
it comes to conditionally including strategies. So far, we have used
conditional weights but this breaks once we get past 10 strategies
(happening in #5083). That is because `prop_oneof` calls
`Union::new_weighted` underneath for anything more than 10 strategies
and this constructor panics on weights of 0.
Fortunately, we can simply get rid of the macro and construct a list
that we conditionally push all valid strategies into. This approach
scales to any number of strategies and doesn't involve any macros.
Refs #5022
The debug IPC service has been useful on Windows, and since there is
more refactoring to do, I want it on Linux too.
With this you can just do `sudo -E target/debug/firezone-client-ipc
debug-ipc-service` and it will launch an IPC service without messing
with systemd or installing anything. (Assuming the directory for the
socket is created)
```[tasklist]
### Before merging
- [ ] Check for regressions in Windows
- [ ] Check for regressions in Linux
```
Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.58 to
1.0.61.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/dtolnay/thiserror/releases">thiserror's
releases</a>.</em></p>
<blockquote>
<h2>1.0.61</h2>
<ul>
<li>Use <code>core::fmt</code> and <code>core::panic</code> to
facilitate <code>error_in_core</code> support (<a
href="https://redirect.github.com/dtolnay/thiserror/issues/299">#299</a>,
thanks <a
href="https://github.com/jordens"><code>@jordens</code></a>)</li>
</ul>
<h2>1.0.60</h2>
<ul>
<li>Resolve unexpected_cfgs warning (<a
href="https://redirect.github.com/dtolnay/thiserror/issues/298">#298</a>)</li>
</ul>
<h2>1.0.59</h2>
<ul>
<li>Unblock testing of rustc <code>debug-fmt-detail</code> option (<a
href="https://redirect.github.com/dtolnay/thiserror/issues/297">#297</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="5c8016393f"><code>5c80163</code></a>
Release 1.0.61</li>
<li><a
href="e3b1b91ced"><code>e3b1b91</code></a>
Format PR 299 with rustfmt</li>
<li><a
href="6b2b871f39"><code>6b2b871</code></a>
Merge pull request <a
href="https://redirect.github.com/dtolnay/thiserror/issues/299">#299</a>
from quartiq/core</li>
<li><a
href="ce974bc2bd"><code>ce974bc</code></a>
also {std -> core}::panic::UnwindSafe</li>
<li><a
href="7b6e35b992"><code>7b6e35b</code></a>
use core::fmt instead of std::fmt</li>
<li><a
href="870d11b830"><code>870d11b</code></a>
Release 1.0.60</li>
<li><a
href="0ccee7c2a1"><code>0ccee7c</code></a>
Merge pull request <a
href="https://redirect.github.com/dtolnay/thiserror/issues/298">#298</a>
from dtolnay/checkcfg</li>
<li><a
href="cf43d0c130"><code>cf43d0c</code></a>
Resolve unexpected_cfgs warning</li>
<li><a
href="e7ad85ee6b"><code>e7ad85e</code></a>
Release 1.0.59</li>
<li><a
href="af477ecbe5"><code>af477ec</code></a>
Merge pull request <a
href="https://redirect.github.com/dtolnay/thiserror/issues/297">#297</a>
from dtolnay/traitident</li>
<li>Additional commits viewable in <a
href="https://github.com/dtolnay/thiserror/compare/1.0.58...1.0.61">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 [serde](https://github.com/serde-rs/serde) from 1.0.197 to
1.0.203.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/serde-rs/serde/releases">serde's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.203</h2>
<ul>
<li>Documentation improvements (<a
href="https://redirect.github.com/serde-rs/serde/issues/2747">#2747</a>)</li>
</ul>
<h2>v1.0.202</h2>
<ul>
<li>Provide public access to RenameAllRules in serde_derive_internals
(<a
href="https://redirect.github.com/serde-rs/serde/issues/2743">#2743</a>)</li>
</ul>
<h2>v1.0.201</h2>
<ul>
<li>Resolve unexpected_cfgs warning (<a
href="https://redirect.github.com/serde-rs/serde/issues/2737">#2737</a>)</li>
</ul>
<h2>v1.0.200</h2>
<ul>
<li>Fix formatting of "invalid type" and "invalid
value" deserialization error messages containing NaN or infinite
floats (<a
href="https://redirect.github.com/serde-rs/serde/issues/2733">#2733</a>,
thanks <a
href="https://github.com/jamessan"><code>@jamessan</code></a>)</li>
</ul>
<h2>v1.0.199</h2>
<ul>
<li>Fix ambiguous associated item when
<code>forward_to_deserialize_any!</code> is used on an enum with
<code>Error</code> variant (<a
href="https://redirect.github.com/serde-rs/serde/issues/2732">#2732</a>,
thanks <a
href="https://github.com/aatifsyed"><code>@aatifsyed</code></a>)</li>
</ul>
<h2>v1.0.198</h2>
<ul>
<li>Support serializing and deserializing
<code>Saturating<T></code> (<a
href="https://redirect.github.com/serde-rs/serde/issues/2709">#2709</a>,
thanks <a
href="https://github.com/jbethune"><code>@jbethune</code></a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="d5bc546ca5"><code>d5bc546</code></a>
Release 1.0.203</li>
<li><a
href="45ae217728"><code>45ae217</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2747">#2747</a>
from dtolnay/variadic</li>
<li><a
href="b7b97dda73"><code>b7b97dd</code></a>
Unindent implementation inside tuple_impl_body macro</li>
<li><a
href="5d3c563d46"><code>5d3c563</code></a>
Document tuple impls as fake variadic</li>
<li><a
href="376185458b"><code>3761854</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2745">#2745</a>
from dtolnay/docsrs</li>
<li><a
href="a8f14840ab"><code>a8f1484</code></a>
Rely on docs.rs to define --cfg=docsrs by default</li>
<li><a
href="9e32a40b1c"><code>9e32a40</code></a>
Release 1.0.202</li>
<li><a
href="87f635e54d"><code>87f635e</code></a>
Release serde_derive_internals 0.29.1</li>
<li><a
href="d4b2dfbde2"><code>d4b2dfb</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2743">#2743</a>
from dtolnay/renameallrules</li>
<li><a
href="f6ab0bc56f"><code>f6ab0bc</code></a>
Provide public access to RenameAllRules in serde_derive_internals</li>
<li>Additional commits viewable in <a
href="https://github.com/serde-rs/serde/compare/v1.0.197...v1.0.203">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>
Currently, we only consult the IP ranges of our configured resources for
the initial connection to a gateway. Once a connection is established,
packets are routed based on an IP range associated with that gateway.
This is inconsistent and actually causes problems in case the user
configures overlapping resources. In particular, adding a resource with
an overlapping but narrower IP network range to a client that is already
connected to a gateway with an overlapping but wider range will cause
all packets for the newly added resource to be routed to the already
connected gateway.
To fix this, we consult the IP network table of resources for each
packet to figure out, which resource is the most appropriate one. Then,
we pick the gateway that is configured for this resource. If we aren't
connected to that gateway or if we don't know about a gateway for this
resource, we emit a connection intent.
In case the portal wants to use an already connected gateway for that
resource, we handle that using the "reuse connection" message to the
portal.
In fixing this, I also realised that I think this has (positive) audit
consequences. In particular, this will now correctly report access to a
resource if it is overlapping as described above (i.e. a narrower
overlapping resource is added whilst being connected to one with a wider
range). I believe that previously, this access would have not been
reported because we would have simply routed the packet to the already
connected gateway.
Fixes: #5054.
DNS in connlib mainly follows the following rules:
1. If there are upstream DNS servers configured in the portal, use
those.
2. Without upstream DNS servers, use the ones configured on the system.
3. Assign one proxy IP per effective DNS server.
We can test these properties using the state machine tests by
introducing an event that connlib emits every time it updates its DNS
servers. Additionally, this unblocks #5083. To resolve DNS resources, we
need to know, which DNS server to send a packet too and thus, we need
knowledge of the assigned proxy IP in the tests.
Currently, all clients learn about these effective DNS servers via the
callbacks. Those are still fairly intertwined in the `Tunnel`. Once we
have the resources to untangle this, we should use the emitted event to
inform the clients about the new DNS servers. I've captured this tech
debt in #5106.
This is a follow-up to #5035. I didn't end up renaming `Tunnel`,
`GatewayState` or `ClientState` but I've added some comments with my
understanding of what the state is we are tracking and tried to group
the fields together in a logical way.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
In order to exercise all codepaths of connlib, we need to send traffic
in both directions. This patch sends ICMP replies from the gateway to
the client upon receipt of an ICMP request.
The routing logic within the state machine test only works if none of
the components have the same IP. We can add a filter to the initially
sampled state to ensure this.
All functions on `GatewayState` and `ClientState` should be pure to
allow testing via property-based tests where we control all inputs,
including time.
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.
Closes#5086
I accidentally modified a function that's used in both Android and
Linux, this PR splits it up into two functions
```[tasklist]
### Before merging
- [x] Check aarch64 deb still signs in (716320)
```
Closes#4995Closes#4925Closes#4997Closes#5047
Supersedes #4965 and #5004.
NOT changing:
- Page description for other Clients. That is still "Firezone
Documentation"
Need these Clients:
- Windows GUI
- Linux headless
- Linux GUI
to have these things documented: (with exact terms)
- Prerequisites
- Installation
- Usage
- Signing in
- Accessing a Resource
- Signing out
- Quitting
- Upgrading
- Diagnostic logs
- Uninstalling
- Troubleshooting
- DNS not reverted after exit
- DNS Resource not accessible
- Known issues
```[tasklist]
### Before merging
- [x] Test Windows GUI instructions
- [x] Add troubleshooting for #5027
- [x] Fill in troubleshooting sections
- [x] Test Linux GUI instructions
- [x] Linux headless - Make sure SIGTERM or Ctrl+C or whatever reverts resolv.conf
- [x] Test Linux Headless instructions
- [x] Page descriptions should be "How to install and use the Firezone $OS $UI client."
- [x] ~~Linux headless - Confirm behaviors and default values of all env vars~~ (skipping - The ones that are used are exercised)
- [x] Grep for TODOs
- [x] Change "un-install" to "uninstall"
- [x] Capitalize "Client" where needed
- [x] Change "IPC service" to "Tunnel service" or something
- [x] Change "SplitDNS" to "Split DNS"
- [ ] Wait for next Client release to be cut
```
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Bumps [redis-macros](https://github.com/daniel7grant/redis-macros) from
0.2.1 to 0.3.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/daniel7grant/redis-macros/releases">redis-macros's
releases</a>.</em></p>
<blockquote>
<h2>v0.3.0</h2>
<h3>Updated</h3>
<ul>
<li>Update dependencies (by <a
href="https://github.com/negezor"><code>@negezor</code></a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/daniel7grant/redis-macros/blob/master/Changelog.md">redis-macros's
changelog</a>.</em></p>
<blockquote>
<h2>[0.3.0] - 2024-04-01</h2>
<h3>Updated</h3>
<ul>
<li>Update dependencies (by <a
href="https://github.com/negezor"><code>@negezor</code></a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0683922ce7"><code>0683922</code></a>
Bump Cargo versions as well</li>
<li><a
href="3db5e1cbc2"><code>3db5e1c</code></a>
Merge pull request <a
href="https://redirect.github.com/daniel7grant/redis-macros/issues/10">#10</a>
from daniel7grant/release/v0.3.0</li>
<li><a
href="ca3c11292c"><code>ca3c112</code></a>
Add contribution</li>
<li><a
href="98daf0aac0"><code>98daf0a</code></a>
Prepare for v0.3.0 release</li>
<li><a
href="2e6f8f53b9"><code>2e6f8f5</code></a>
Merge pull request <a
href="https://redirect.github.com/daniel7grant/redis-macros/issues/9">#9</a>
from negezor/update-dependencies</li>
<li><a
href="45dca719c3"><code>45dca71</code></a>
Merge branch 'master' into update-dependencies</li>
<li><a
href="55ff18410e"><code>55ff184</code></a>
Merge pull request <a
href="https://redirect.github.com/daniel7grant/redis-macros/issues/8">#8</a>
from negezor/derive-syn2</li>
<li><a
href="bf0c11bec7"><code>bf0c11b</code></a>
Merge pull request <a
href="https://redirect.github.com/daniel7grant/redis-macros/issues/7">#7</a>
from negezor/update-ci</li>
<li><a
href="ba058acb7a"><code>ba058ac</code></a>
Remove unnecessary parameter from toolchain</li>
<li><a
href="a4ecdc4547"><code>a4ecdc4</code></a>
chore(deps): update deadpool-redis to 0.15</li>
<li>Additional commits viewable in <a
href="https://github.com/daniel7grant/redis-macros/compare/v0.2.1...v0.3.0">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>
Added a simple check in docker-init.sh so it's possible to provide a
file path instead of plain token.
---------
Co-authored-by: Lis <olgagorbushina1980@gmail.com>
This call always results in an error because the GUI runs unprivileged
on both Linux and Windows now, so it can't control DNS or deactivate DNS
control. The IPC service has taken over all that, so the GUI not only
shouldn't do it, it can't do it.
<img width="568" alt="image"
src="https://github.com/firezone/firezone/assets/13400041/ad1b861f-4f3e-453a-94b5-d6f21c9eb198">
Closes#5015.
This way if the user opens and closes the GUI without doing anything,
the Welcome screen still appears until they successfully sign in.
Previously the `ran_before` flag was set after the first GUI startup.
Tested on Windows once.
Bumps [arboard](https://github.com/1Password/arboard) from 3.3.2 to
3.4.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/1Password/arboard/releases">arboard's
releases</a>.</em></p>
<blockquote>
<h2>v3.4.0</h2>
<h3>Added</h3>
<ul>
<li>Added a <code>wait_until</code> method for Linux, as a superset of
the existing <code>wait</code> functionality.
This is a helper for letting an application wait without manual timeout
handling.</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>Transparency in copied images now behaves better in certain Windows
apps.</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Updated <code>image</code> to <code>0.25</code>.</li>
<li>Removed direct <code>thiserror</code> dependency.</li>
<li>Fixed Linux documentation links</li>
<li>Raised MSRV to 1.67.1</li>
<li>Reverted timeout behavior of <code>Clipboard::new()</code> on
platforms using X11. Applications are
encouraged to wrap constructor calls in their own thread/channel timeout
mechanisms instead
to make sure the behavior matches each usecase.</li>
<li>Migrated away from <code>objc</code> to the <code>objc2</code>
ecosystem for the Apple clipboard implementation.</li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/1Password/arboard/compare/v3.3.2...v3.4.0">https://github.com/1Password/arboard/compare/v3.3.2...v3.4.0</a></p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/1Password/arboard/blob/master/CHANGELOG.md">arboard's
changelog</a>.</em></p>
<blockquote>
<h2>3.4.0 on 2024-29-04</h2>
<h3>Added</h3>
<ul>
<li>Added a <code>wait_until</code> method for Linux, as a superset of
the existing <code>wait</code> functionality.
This is a helper for letting an application wait without manual timeout
handling.</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>Transparency in copied images now behaves better in certain Windows
apps.</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Updated <code>image</code> to <code>0.25</code>.</li>
<li>Removed direct <code>thiserror</code> dependency.</li>
<li>Fixed Linux documentation links</li>
<li>Raised MSRV to 1.67.1</li>
<li>Reverted timeout behavior of <code>Clipboard::new()</code> on
platforms using X11. Applications are
encouraged to wrap constructor calls in their own thread/channel timeout
mechanisms instead
to make sure the behavior matches each usecase.</li>
<li>Migrated away from <code>objc</code> to the <code>objc2</code>
ecosystem for the Apple clipboard implementation.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="151e679ee5"><code>151e679</code></a>
Release 3.4.0</li>
<li><a
href="610e29ba81"><code>610e29b</code></a>
Remove direct thiserror dependency</li>
<li><a
href="83740b7ab0"><code>83740b7</code></a>
Copy image as PNG file on Windows (<a
href="https://redirect.github.com/1Password/arboard/issues/141">#141</a>)</li>
<li><a
href="0bff1e07ea"><code>0bff1e0</code></a>
Use objc2 and its framework crates</li>
<li><a
href="1cca83d7e5"><code>1cca83d</code></a>
Revert "add timeout to RustConnection::connect to X11
server"</li>
<li><a
href="b4646f6c5f"><code>b4646f6</code></a>
Increase version of clipboard-win used by default</li>
<li><a
href="e2846f9288"><code>e2846f9</code></a>
Fix clippy errors</li>
<li><a
href="2f4b502508"><code>2f4b502</code></a>
Move <code>WaitConfig</code> to src/platform/linux/mod.rs, use
<code>WaitConfig</code> inside `stru...</li>
<li><a
href="6cf324cc44"><code>6cf324c</code></a>
Added <code>WaitConfig</code>, fix <code>wait_until</code> note in
docs</li>
<li><a
href="eabb191df0"><code>eabb191</code></a>
add notice for X11 in <code>SetExtLinux#wait_until</code> docs</li>
<li>Additional commits viewable in <a
href="https://github.com/1Password/arboard/compare/v3.3.2...v3.4.0">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>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Ready for review.
Closes#3712.
Supersedes #4940.
Refs #4963.
I haven't figured out if it needs any new automated tests (unit,
integration, etc.) but the code itself is ready for review. There is
more refactoring that could be done, or could be left for later.
```[tasklist]
- [x] Move wintun setup from GUI to IPC service / headless client
- [x] Make sure the device ID is in a sensible place
- [x] Export IPC service logs in the zips
- [x] Test GUI + SC IPC service on Windows (f4db808919a passed)
- [x] Make sure IPC service does not busy-loop
- [x] Test un-install checklist for Windows
- [x] Test upgrade checklist for Windows
- [x] Test GUI + systemd IPC service on Linux (c4ab7e7 passed)
- [x] Test upgrade checklist for Linux
- [x] Test un-install checklist for Linux
- [x] Make sure the IPC service logs out and deactivates DNS control if the GUI crashes
- [x] Test network changing
- [x] (it's intended behavior) ~~Look into spurious `on_update_resources` (fad86babd7)~~
- [x] ~~Test max partition time on offline laptop~~ (I ended up just setting a 30-day default in the code)
- [x] Make sure headless Client does not busy-loop
- [x] Test standalone headless on Linux
- [ ] Add unit / integration tests
- [ ] Think about security a bit #3971
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
The API of connlib is designed around a uni-directional dataflow where
commands flow one way and events flow the other way. By design, this
creates a system of eventual consistency: We don't exactly know when
connlib will emit an event. This is important because it gives us
flexibility in what the internals of connlib look like. It also forces
the downstream apps to be able to handle any event at any point which
avoids bugs where clients rely on a certain order that may just be an
implementation detail.
To achieve all of this, it is important that we don't introduce APIs
with return values. As soon as a function returns a value, it commits to
being able to compute this return value _synchronously_. Any refactoring
that may make the computation of the return value asynchronous is then a
breaking change.
Consequently, APIs like `handle_timeout` should never return a value.
Instead, they should queue an event that the layer above reacts to
accordingly.
