## Abstract
This pull-request implements the first stage of off-loading routing of
TURN data channel messages to the kernel via an eBPF XDP program. In
particular, the eBPF kernel implemented here **only** handles the
decapsulation of IPv4 data channel messages into their embedded UDP
payload. Implementation of other data paths, such as the receiving of
UDP traffic on an allocation and wrapping it in a TURN channel data
message is deferred to a later point for reasons explained further down.
As it stands, this PR implements the bare minimum for us to start
experimenting and benefiting from eBPF. It is already massive as it is
due to the infrastructure required for actually doing this. Let's dive
into it!
## A refresher on TURN channel-data messages
TURN specifies a channel-data message for relaying data between two
peers. A channel data message has a fixed 4-byte header:
- The first two bytes specify the channel number
- The second two bytes specify the length of the encapsulated payload
Like all TURN traffic, channel data messages run over UDP by default,
meaning this header sits at the very front of the UDP payload. This will
be important later.
After making an allocation with a TURN server (i.e. reserving a port on
the TURN server's interfaces), a TURN client can bind channels on that
allocation. As such, channel numbers are scoped to a client's
allocation. Channel numbers are allocated by the client within a given
range (0x4000 - 0x4FFF). When binding a channel, the client specifies
the remote's peer address that they'd like the data sent on the channel
to be sent to.
Given this setup, when a TURN server receives a channel data message, it
first looks at the sender's IP + port to infer the allocation (a client
can only ever have 1 allocation at a time). Within that allocation, the
server then looks for the channel number and retrieves the target socket
address from that. The allocation itself is a port on the relay's
interface. With that, we can now "unpack" the payload of the channel
data message and rewrite it to the new receiver:
- The new source IP can be set from the old dst IP (when operating in
user-space mode this is irrelevant because we are working with the
socket API).
- The new source port is the client's allocation.
- The new destination IP is retrieved from the mapping retrieved via the
channel number.
- The new destination port is retrieved from the mapping retrieved via
the channel number.
Last but not least, all that is left is removing the channel data header
from the UDP payload and we can send out the packet. In other words, we
need to cut off the first 4 bytes of the UDP payload.
## User-space relaying
At present, we implement the above flow in user-space. This is tricky to
do because we need to bind _many_ sockets, one for each possible
allocation port (of which there can be 16383). The actual work to be
done on these packets is also extremely minimal. All we do is cut off
(or add on) the data-channel header. Benchmarks show that we spend
pretty much all of our time copying data between user-space and
kernel-space. Cutting this out should give us a massive increase in
performance.
## Implementing an eBPF XDP TURN router
eBPF has been shown to be a very efficient way of speeding up a TURN
server [0]. After many failed experiments (e.g. using TC instead of XDP)
and countless rabbit-holes, we have also arrived at the design
documented within the paper. Most notably:
- The eBPF program is entirely optional. We try to load it on startup,
but if that fails, we will simply use the user-space mode.
- Retaining the user-space mode is also important because under certain
circumstances, the eBPF kernel needs to pass on the packet, for example,
when receiving IPv4 packets with options. Those make the header
dynamically-sized which makes further processing difficult because the
eBPF verifier disallows indexing into the packet with data derived from
the packet itself.
- In order to add/remove the channel-data header, we shift the packet
headers backwards / forwards and leave the payload in place as the
packet headers are constant in size and can thus easily and cheaply be
copied out.
In order to perform the relaying flow explained above, we introduce maps
that are shared with user-space. These maps go from a tuple of
(client-socket, channel-number) to a tuple of (allocation-port,
peer-socket) and thus give us all the data necessary to rewrite the
packet.
## Integration with our relay
Last but not least, to actually integrate the eBPF kernel with our
relay, we need to extend the `Server` with two more events so we can
learn, when channel bindings are created and when they expire. Using
these events, we can then update the eBPF maps accordingly and therefore
influence the routing behaviour in the kernel.
## Scope
What is implemented here is only one of several possible data paths.
Implementing the others isn't conceptually difficult but it does
increase the scope. Landing something that already works allows us to
gain experience running it in staging (and possibly production).
Additionally, I've hit some issues with the eBPF verifier when adding
more codepaths to the kernel. I expect those to be possible to resolve
given sufficient debugging but I'd like to do so after merging this.
---
Depends-On: #8506
Depends-On: #8507
Depends-On: #8500Resolves: #8501
[0]: https://dl.acm.org/doi/pdf/10.1145/3609021.3609296
Unfortunately, the cwd I set for the action didn't seem to apply so it
checked the links for the entire repo instead which - together with the
`--base` setting, produces a lot of errors for relative links.
In addition, lychee doesn't currently support having the `.lycheeignore`
file in a subdirectory (see related link), meaning we unfortunately have
to put yet another dot file in the root of our repository.
Related: https://github.com/lycheeverse/lychee-action/issues/205
From the perspective of any application, Firezone is a layer-3 network
and will thus use the host's networking stack to form IP packets for
whichever application protocol is in use (UDP, TCP, etc). These packets
then get encapsulated into UDP packets by Firezone and sent to a
Gateway.
As a result of this design, the IP header seen by the networking stacks
of the Client and the receiving service are not visible to any
intermediary along the network path of the Client and Gateway.
In case this network path is congested and middleboxes such as routers
need to drop packets, they will look at the ECN bits in the IP header
(of the UDP packet generated by a Client or Gateway) and flip a bit in
case the previous value indicated support for ECN (`0x01` or `0x10`).
When received by a network stack that supports ECN, seeing `0x11` means
that the network path is congested and that it must reduce its
send/receive windows (or otherwise throttle the connection).
At present, this doesn't work with Firezone because of the
aforementioned encapsulation of IP packets. To support ECN, we need to
therefore:
- Copy ECN bits from a received IP packet to the datagram that
encapsulates it: This ensures that if the Client's network stack support
ECN, we mirror that support on the wire.
- Copy ECN bits from a received datagram to the IP packet the is sent to
the TUN device: This ensures that if the "Congestion Experienced" bit
get set along the network path between Client and Gateway, we reflect
that accordingly on the IP packet emitted by the TUN device.
Resolves: #3758
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Turns out we have several broken links on our website currently. Broken
links don't make a good impression so we should catch them as early as
possible.
Due to how our website is laid out, that isn't always possible to catch
these dead links in CI. The next best thing we can do is run a cron-job
in our CI that checks our sourcecode and makes sure all links (including
relative ones) are reachable.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
For #8501, we need to install a nightly toolchain in our CI system in
order to compile to eBPF kernel. We already use a nightly toolchain for
one of the static analysis tools.
In this PR, we extend our `setup-rust` action to install the nightly
toolchain for us which allows us to reuse that later.
For #7518, we need an additional toolchain (nightly) to compile the
relay and installing that within `cross` is quite complicated. Our
cross-compiling needs are actually quite simple to satisfy. All we need
is to download the corresponding musl toolchain and set some environment
variables. The rest is handled by cargo.
Removes the google gateway module in this repo because:
- We already reference this module from our `environments` repo.
- Customers are already using the dedicated module
- Any actually pointing to the module in this repo will have issues
because Terraform [automatically tries to clone
submodules](https://github.com/hashicorp/terraform/issues/34917).
Turns out cloud-init has native support for configuring swapfiles, so we
use that here and make it configurable.
The `environments` submodule will be updated to inject the current value
into here.
~~Apparently `xcodebuild` doesn't bubble these up from CLI
invocations.~~
The `swiftlint` CLI binary isn't installed on the GitHub runners, so we
need to install it. This PR also explicitly runs `swiftlint` before any
build operations to display a nicer diff if files were changed as a
result of the fixing.
A sizeable chunk of Firezone's Rust components deal with parsing,
manipulating and emitting DNS queries and responses. The API surface of
DNS is quite large and to make handling of all corner-cases easier, we
depend on the `domain` library to do the heavy-lifting for us.
For better or worse, `domain` follows a lazy-parsing approach. Thus,
creating a new DNS message doesn't actually verify that it is in fact
valid. Within Firezone, we make several assumptions around DNS messages,
such as that they will only ever contain a single question.
Historically, DNS allows for multiple questions per query but in
practise, nobody uses that.
Due to how we handle DNS in Firezone, manipulating these messages
happens in multiple places. That combined with the lazy-parsing approach
from `domain` warrants having our own `dns-types` library that wraps
`domain` and provides us with types that offer the interface we need in
the rest of the codebase.
Resolves: #7019
Search domains are a way of performing a DNS lookup without typing the
full-qualified domain name. For example, with a search domain of
`example.com`, performing a DNS query for `app` will automatically
expand the query to `app.example.com`. At present, this doesn't work
with Firezone because there is no way to configure an account-wide
search-domain.
With this PR, we extend the `Interface` message sent by the portal to
also include an optional `search_domain` field that must be a valid
domain name. If set, `connlib`'s DNS stub resolver will now append this
domain to all single-label queries and match the resulting domain
against all active DNS resource.
On Linux - with `systemd-resolved` as the DNS backend - we need to set
the search domain on the TUN interface as well and enable LLMNR in order
to be able to intercept these queries. `resolved` expands the query for
us, however, meaning with this configuration, we don't actually receive
a single-label query in `connlib`. Instead, we directly see
`app.example.com` when we type `host app` or `dig +search app` and have
`example.com` as our search domain.
MacOS has a similar system but with a different fallack. There, the
operating system will first try all configured search domains on the
system (typically just the ones set prior to Firezone starting), and
send queries for FQDN to all resolvers. If none of the resolvers
(including Firezone's stub resolver) return results, it sends the
single-label query directly to the primary resolver. To handle this
case, Firezone needs to know about the search-domain and expand it
itself when it receives the single-label query. In the future, we may
want to look into how we can configure MacOS such that it performs this
expansion for us.
On Windows and Android, queries for a single-label domain will be
directly sent to Firezone's stub resolver where we then hit the same
codepath as explained above.
Specifically, the way this codepath works is that if we receive a
single-label query AND we have a search-domain set, we expand it and
match that particular query against our list of resources. In every
other case, we continue on with the single-label domain.
Related: #8365Fixes: #8377
- Adds more actor groups to the existing `oidc_provider`
- Configures a rand seed so our seed data is reproducible across
machines
- Formats the seeds file to allow for some refactoring a later PR
- Adds a `Mock` identity provider adapter with sync enabled
## Description
We want to resolve DNS queries of type SRV & TXT for DNS resources
within the network context of the site that is hosting the DNS resource
itself. This allows admins to e.g. deploy dedicated nameservers into
those sites and have them resolve their SRV and TXT records to names
that are scoped to that particular site.
SRV records themselves return more domains which - if they are
configured as DNS resources - will be intercepted and then routed to the
correct site.
Prior to this PR, SRV & TXT records got resolved by the DNS server
configured on the client (or the server defined in the Firezone portal),
even if the domain in question was a DNS resource. This effectively
meant that those SRV records have to be valid globally and could not be
specific to the site that the DNS resource is hosted in.
## Example
Say we have these wildcard DNS resources:
- `**.department-a.example.com`
- `**.department-b.example.com`
Each of these DNS resources is assigned to a different site. If we now
issue an SRV DNS query to `_my-service.department-a.example.com`, we may
receive back the following records:
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service1.department-a.example.com.`
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service2.department-a.example.com.`
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service3.department-a.example.com.`
Notice how the SRV records point to domains that will also match the
wildcard DNS resource above! If that is the case, Firezone will also
intercept A & AAAA queries for this service (which are a natural
follow-up from an application making an SRV query). As a result, traffic
for `my-service1.department-a.example.com` will be routed to the same
site the DNS resource is defined in. If the returned domains don't match
the wildcard DNS resource, the traffic will either not be intercepted at
all (if it is not a DNS resource) or routed to whichever site defines
the corresponding DNS resource.
All of these scenarios may be what the admin wants. If the SRV records
defined for the DNS resource are globally valid (and e.g. not even
resources), then resolving them using the Client's system resolver may
be all that is needed. If the services are running in a dedicated site,
that traffic should indeed be routed to that site.
As such, Firezone itself cannot make any assumption about the structure
of these records at all. The only thing that is enabled with this PR is
that IF the structure happens to match the same DNS resource, it allows
admins to deploy site-specific services that resolve their concrete
domains via SRV records.
## Testing
The implementation is tested using our property-based testing framework.
In order to cover these cases, we introduce the notion of site-specific
DNS records which are sampled when we create each individual Gateway.
When selecting a domain to query for, all global DNS records and the
site-specific ones are merged and a domain name and query type is chosen
at random.
At present, this testing framework does not assert that the DNS response
itself is correct, i.e. that it actually returned the site-specific
record. We don't assert this for any other DNS queries, hence this is
left for a future extension. We do assert using our regression grep's
that we hit the codepath of querying an SRV or TXT record for a DNS
resource.
Related: #8221
[//]: # (dependabot-start)
⚠️ **Dependabot is rebasing this PR** ⚠️
Rebasing might not happen immediately, so don't worry if this takes some
time.
Note: if you make any changes to this PR yourself, they will take
precedence over the rebase.
---
[//]: # (dependabot-end)
Bumps
[docker/metadata-action](https://github.com/docker/metadata-action) from
5.6.1 to 5.7.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/docker/metadata-action/releases">docker/metadata-action's
releases</a>.</em></p>
<blockquote>
<h2>v5.7.0</h2>
<ul>
<li>Global expressions support for labels and annotations by <a
href="https://github.com/crazy-max"><code>@crazy-max</code></a> in <a
href="https://redirect.github.com/docker/metadata-action/pull/489">docker/metadata-action#489</a></li>
<li>Support disabling outputs as environment variables by <a
href="https://github.com/omus"><code>@omus</code></a> in <a
href="https://redirect.github.com/docker/metadata-action/pull/497">docker/metadata-action#497</a></li>
<li>Bump <code>@docker/actions-toolkit</code> from 0.44.0 to 0.56.0 in
<a
href="https://redirect.github.com/docker/metadata-action/pull/507">docker/metadata-action#507</a>
<a
href="https://redirect.github.com/docker/metadata-action/pull/509">docker/metadata-action#509</a></li>
<li>Bump csv-parse from 5.5.6 to 5.6.0 in <a
href="https://redirect.github.com/docker/metadata-action/pull/482">docker/metadata-action#482</a></li>
<li>Bump moment-timezone from 0.5.46 to 0.5.47 in <a
href="https://redirect.github.com/docker/metadata-action/pull/501">docker/metadata-action#501</a></li>
<li>Bump semver from 7.6.3 to 7.7.1 in <a
href="https://redirect.github.com/docker/metadata-action/pull/504">docker/metadata-action#504</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/docker/metadata-action/compare/v5.6.1...v5.7.0">https://github.com/docker/metadata-action/compare/v5.6.1...v5.7.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="902fa8ec7d"><code>902fa8e</code></a>
Merge pull request <a
href="https://redirect.github.com/docker/metadata-action/issues/504">#504</a>
from docker/dependabot/npm_and_yarn/semver-7.7.1</li>
<li><a
href="c30b9c27e6"><code>c30b9c2</code></a>
chore: update generated content</li>
<li><a
href="0698804aab"><code>0698804</code></a>
chore(deps): Bump semver from 7.6.3 to 7.7.1</li>
<li><a
href="bb3eecaaf8"><code>bb3eeca</code></a>
Merge pull request <a
href="https://redirect.github.com/docker/metadata-action/issues/501">#501</a>
from docker/dependabot/npm_and_yarn/moment-timezone-0...</li>
<li><a
href="94a839cf6a"><code>94a839c</code></a>
chore: update generated content</li>
<li><a
href="ecd51a0f6a"><code>ecd51a0</code></a>
Merge pull request <a
href="https://redirect.github.com/docker/metadata-action/issues/509">#509</a>
from docker/dependabot/npm_and_yarn/docker/actions-to...</li>
<li><a
href="a85b1dbfe6"><code>a85b1db</code></a>
chore(deps): Bump <code>@docker/actions-toolkit</code> from 0.55.0 to
0.56.0</li>
<li><a
href="5a76a0efcf"><code>5a76a0e</code></a>
chore(deps): Bump moment-timezone from 0.5.46 to 0.5.47</li>
<li><a
href="1cc4a9856a"><code>1cc4a98</code></a>
Merge pull request <a
href="https://redirect.github.com/docker/metadata-action/issues/482">#482</a>
from docker/dependabot/npm_and_yarn/csv-parse-5.6.0</li>
<li><a
href="d84de1e022"><code>d84de1e</code></a>
chore: update generated content</li>
<li>Additional commits viewable in <a
href="369eb591f4...902fa8ec7d">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
[docker/build-push-action](https://github.com/docker/build-push-action)
from 6.13.0 to 6.15.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/docker/build-push-action/releases">docker/build-push-action's
releases</a>.</em></p>
<blockquote>
<h2>v6.15.0</h2>
<ul>
<li>Bump <code>@docker/actions-toolkit</code> from 0.55.0 to 0.56.0 in
<a
href="https://redirect.github.com/docker/build-push-action/pull/1330">docker/build-push-action#1330</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/docker/build-push-action/compare/v6.14.0...v6.15.0">https://github.com/docker/build-push-action/compare/v6.14.0...v6.15.0</a></p>
<h2>v6.14.0</h2>
<ul>
<li>Bump <code>@docker/actions-toolkit</code> from 0.53.0 to 0.55.0 in
<a
href="https://redirect.github.com/docker/build-push-action/pull/1324">docker/build-push-action#1324</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/docker/build-push-action/compare/v6.13.0...v6.14.0">https://github.com/docker/build-push-action/compare/v6.13.0...v6.14.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="471d1dc4e0"><code>471d1dc</code></a>
Merge pull request <a
href="https://redirect.github.com/docker/build-push-action/issues/1330">#1330</a>
from docker/dependabot/npm_and_yarn/docker/actions-t...</li>
<li><a
href="b89ff0a6f2"><code>b89ff0a</code></a>
chore: update generated content</li>
<li><a
href="1e3ae3a4d3"><code>1e3ae3a</code></a>
chore(deps): Bump <code>@docker/actions-toolkit</code> from 0.55.0 to
0.56.0</li>
<li><a
href="b16f42f92a"><code>b16f42f</code></a>
Merge pull request <a
href="https://redirect.github.com/docker/build-push-action/issues/1325">#1325</a>
from crazy-max/buildx-edge</li>
<li><a
href="dc0fea5e62"><code>dc0fea5</code></a>
ci: update buildx to edge and buildkit to latest</li>
<li><a
href="0adf995921"><code>0adf995</code></a>
Merge pull request <a
href="https://redirect.github.com/docker/build-push-action/issues/1324">#1324</a>
from docker/dependabot/npm_and_yarn/docker/actions-t...</li>
<li><a
href="d88cd289df"><code>d88cd28</code></a>
chore: update generated content</li>
<li><a
href="3d09a6bd70"><code>3d09a6b</code></a>
chore(deps): Bump <code>@docker/actions-toolkit</code> from 0.53.0 to
0.55.0</li>
<li>See full diff in <a
href="ca877d9245...471d1dc4e0">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
[lycheeverse/lychee-action](https://github.com/lycheeverse/lychee-action)
from 2.2.0 to 2.3.0.
<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 2.3.0</h2>
<h2>What's Changed</h2>
<ul>
<li>feat: support ARM workers by <a
href="https://github.com/LesnyRumcajs"><code>@LesnyRumcajs</code></a>
in <a
href="https://redirect.github.com/lycheeverse/lychee-action/pull/273">lycheeverse/lychee-action#273</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a
href="https://github.com/LesnyRumcajs"><code>@LesnyRumcajs</code></a>
made their first contribution in <a
href="https://redirect.github.com/lycheeverse/lychee-action/pull/273">lycheeverse/lychee-action#273</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/lycheeverse/lychee-action/compare/v2...v2.3.0">https://github.com/lycheeverse/lychee-action/compare/v2...v2.3.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="f613c4a64e"><code>f613c4a</code></a>
feat: support ARM workers (<a
href="https://redirect.github.com/lycheeverse/lychee-action/issues/273">#273</a>)</li>
<li>See full diff in <a
href="f796c8b7d4...f613c4a64e">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
[actions/upload-artifact](https://github.com/actions/upload-artifact)
from 4.6.0 to 4.6.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/actions/upload-artifact/releases">actions/upload-artifact's
releases</a>.</em></p>
<blockquote>
<h2>v4.6.1</h2>
<h2>What's Changed</h2>
<ul>
<li>Update to use artifact 2.2.2 package by <a
href="https://github.com/yacaovsnc"><code>@yacaovsnc</code></a> in <a
href="https://redirect.github.com/actions/upload-artifact/pull/673">actions/upload-artifact#673</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/actions/upload-artifact/compare/v4...v4.6.1">https://github.com/actions/upload-artifact/compare/v4...v4.6.1</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4cec3d8aa0"><code>4cec3d8</code></a>
Merge pull request <a
href="https://redirect.github.com/actions/upload-artifact/issues/673">#673</a>
from actions/yacaovsnc/artifact_2.2.2</li>
<li><a
href="e9fad966cc"><code>e9fad96</code></a>
license cache update for artifact</li>
<li><a
href="b26fd06e9d"><code>b26fd06</code></a>
Update to use artifact 2.2.2 package</li>
<li>See full diff in <a
href="65c4c4a1dd...4cec3d8aa0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.47.32 to 2.49.9.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.49.9</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.30.0.</li>
</ul>
<h2>2.49.8</h2>
<ul>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.11.2.</p>
</li>
<li>
<p>Update <code>cargo-audit@latest</code> to 0.21.2.</p>
</li>
</ul>
<h2>2.49.7</h2>
<ul>
<li>Update <code>cargo-deny@latest</code> to 0.18.1.</li>
</ul>
<h2>2.49.6</h2>
<ul>
<li>Update <code>cargo-lambda@latest</code> to 1.7.0.</li>
</ul>
<h2>2.49.5</h2>
<ul>
<li>
<p>Update <code>wasmtime@latest</code> to 30.0.2.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.123.</p>
</li>
</ul>
<h2>2.49.4</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.29.10.</li>
</ul>
<h2>2.49.3</h2>
<ul>
<li>
<p>Update <code>wash@latest</code> to 0.39.0.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.92.</p>
</li>
</ul>
<h2>2.49.2</h2>
<ul>
<li>
<p>Update <code>sccache@latest</code> to 0.10.0.</p>
</li>
<li>
<p>Update <code>cargo-machete@latest</code> to 0.8.0.</p>
</li>
</ul>
<h2>2.49.1</h2>
<ul>
<li>Update <code>cargo-deny@latest</code> to 0.18.0.</li>
</ul>
<h2>2.49.0</h2>
<ul>
<li>Allow installing pre-release versions using binstall. (<a
href="https://redirect.github.com/taiki-e/install-action/pull/868">#868</a>)</li>
</ul>
<h2>2.48.22</h2>
<ul>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.11.1.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.122.</p>
</li>
</ul>
<h2>2.48.21</h2>
<ul>
<li>
<p>Update <code>wasmtime@latest</code> to 30.0.1.</p>
</li>
<li>
<p>Update <code>syft@latest</code> to 1.20.0.</p>
</li>
</ul>
<h2>2.48.20</h2>
<ul>
<li>Update <code>cargo-udeps@latest</code> to 0.1.55.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<h2>[2.49.9] - 2025-03-01</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.30.0.</li>
</ul>
<h2>[2.49.8] - 2025-02-28</h2>
<ul>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.11.2.</p>
</li>
<li>
<p>Update <code>cargo-audit@latest</code> to 0.21.2.</p>
</li>
</ul>
<h2>[2.49.7] - 2025-02-27</h2>
<ul>
<li>Update <code>cargo-deny@latest</code> to 0.18.1.</li>
</ul>
<h2>[2.49.6] - 2025-02-27</h2>
<ul>
<li>Update <code>cargo-lambda@latest</code> to 1.7.0.</li>
</ul>
<h2>[2.49.5] - 2025-02-25</h2>
<ul>
<li>
<p>Update <code>wasmtime@latest</code> to 30.0.2.</p>
</li>
<li>
<p>Update <code>release-plz@latest</code> to 0.3.123.</p>
</li>
</ul>
<h2>[2.49.4] - 2025-02-25</h2>
<ul>
<li>Update <code>typos@latest</code> to 1.29.10.</li>
</ul>
<h2>[2.49.3] - 2025-02-25</h2>
<ul>
<li>
<p>Update <code>wash@latest</code> to 0.39.0.</p>
</li>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.92.</p>
</li>
</ul>
<h2>[2.49.2] - 2025-02-25</h2>
<ul>
<li>Update <code>sccache@latest</code> to 0.10.0.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0b63bc859f"><code>0b63bc8</code></a>
Release 2.49.9</li>
<li><a
href="366fcd03e0"><code>366fcd0</code></a>
Update <code>typos@latest</code> to 1.30.0</li>
<li><a
href="dccf3df6e0"><code>dccf3df</code></a>
Release 2.49.8</li>
<li><a
href="a1324e40ca"><code>a1324e4</code></a>
Update <code>cargo-binstall@latest</code> to 1.11.2</li>
<li><a
href="f0776fc234"><code>f0776fc</code></a>
Update <code>cargo-audit@latest</code> to 0.21.2</li>
<li><a
href="ada1a57be8"><code>ada1a57</code></a>
Release 2.49.7</li>
<li><a
href="afc83a47c0"><code>afc83a4</code></a>
Update <code>cargo-deny@latest</code> to 0.18.1</li>
<li><a
href="3fc1605ecf"><code>3fc1605</code></a>
Release 2.49.6</li>
<li><a
href="85ca29eaeb"><code>85ca29e</code></a>
Update <code>cargo-lambda@latest</code> to 1.7.0</li>
<li><a
href="93a6e1f102"><code>93a6e1f</code></a>
ci: Open update manifest PR also from workflow_dispatch</li>
<li>Additional commits viewable in <a
href="65835784ac...0b63bc859f">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
A particular version of Xcode locks in particular versions of SDKs to
build against. If we hardcode this, the benefit is that we have a
predictable and repeatable build environment.
The downside is whenever GitHub updates its macOS runner images, we
could fail to build due to a version mismatch.
In general, drift between Xcode versions isn't a problem, and tracking
the latest will more closely track developer's machines.
This moves our current GCP infra to a new firezone/environments repo.
The existing Git history is preserved, and CI config is updated to clone
this submodule before running any terraform jobs.
To my knowledge we don't rely on this particular functionality from
hackney. Unfortunately, we don't control the `hackney` version used by
deps, and there is no non-vulnerable version ready yet, so we ignore the
advisory for now.
A fuse has been set to fire one week from now.
