I finally figured out why the smoke test script was being funny. It
turns out that the TURN client I still had lying around in the `gateway`
binary was reading from the UDP socket in the background and thus
sometimes grabbed the relayed data and wanted to interpret it as a STUN
packet.
However, for this test, the `gateway` doesn't actually need a TURN
client at all. It communicates with the relay as if it were the `client`
itself.
By modifying the script to only work on localhost, we can avoid use of a
TURN client altogether in the relay and make this script deterministic
which is a big win for our CI confidence!
- Add 1.0 blogpost
- Update font to `Public Sans` since it has all weights and offers
better readability
- Various layout/style fixes
- Disable kotlin draft release job
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Andrew Dryga <andrew@dryga.com>
- Replaced connlib dependency to use `rust/connlib/clients/android/lib`
project
- Added `rust-android-gradle` to android project
- Set the `cargo build` target directory to
`rust/connlib/clients/android/lib/build/cargo-target`
- Moved `logger`, `session`, and `vpn` classes to their independent
packages.
- Added `SessionCallback` contract for the session callbacks.
---------
Signed-off-by: Pratik Velani <pratikvelani@gmail.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
This PR improves the build process for the macOS / iOS apps by building
connlib as part of the macOS / iOS app build.
Fixesfirezone/product#625.
This is how the build would work after this PR:
- `build-rust.sh` creates `libconnlib.a` for the appropriate target
triples only. lipo is not used. When creating macOS debug builds, it’s
built only for the native architecture.
- The network extension targets in the Xcode project set a library
search path as the cargo target dir, so that the Xcode build for a
target triple can pickup the appropriate `libconnlib.a` at link time.
Swift code reorganizations:
- connlib’s Adapter has moved to the main app
- connlib’s CallbackHandler’s logic has moved to Adapter, which is set
as CallbackHandler’s delegate. The CallbackHandler serves as an
interface to receive callbacks from the FFI. In case we need to change
the FFI, CallbackHandler should change as well, so it remains in the
connlib directory. In case of changes to the Rust FFI, as part of the
Rust FFI change PR, we can modify the CallbackHandler class and leave
the delegate unchanged, so that the app can continue to be built without
errors.
- `Connlib.xcodeproject` and build scripts for building
`Connlib.xcframework` are removed
- Connlib headers and Swift files are copied to
`FirezoneNetworkExtension/Connlib` as part of the build process, and
used from there.
Rust build changes:
- The rust target dir remains the same, but it’s ~~passed explicitly as
`--target-dir`~~ used to set `CARGO_TARGET_DIR`, so that the same target
dir can be used to populate Xcode’s library search paths
- The `build.rs` for connlib-apple had lots of code to build Swift code
as part of the Rust build. This PR reverts it to the previous simple
version. With this PR, building connlib-apple (i.e. running
`build-rust.sh`) only builds the Rust code.
- ~~We set `cargo:rerun-if-env-changed=CONNLIB_MOCK`.~~ We don't set
this because it's not required.
- The Rust CI job for building connlib-apple is removed. It's built when
the macOS / iOS apps are built in swift.yml. This means that with this
PR, connlib-apple is tested only when `rust/connlib/**` changes, not
when `rust/**` changes. Is that ok?
Other changes not directly related to the build process change but part
of this PR:
- There’s a cleanup script: `./cleanup.sh`
- Fixed a typo in `swift-pass-checks.yml`: “paths-ginore”
~~This is an attempt to fix the CI bug
[here](https://github.com/firezone/firezone/actions/runs/5491388141/jobs/10007864417#step:4:1638)
possibly introduced in
[d9eb2d18](https://github.com/firezone/firezone/commit/d9eb2d18#diff-88bd94db0d5cfd5f0617b7c4ed48c0212597378ed7e28714c5d86c95999b4c7dR29)
and uncovered / exacerbated in Elixir 1.15~~
Edit: looks like this ended up being a couple cache issues with GitHub
actions:
1. The `elixir_api-container-build` cache would always overwrite the
`elixir_web-container-build` on subsequent builds of the same
`github.ref_name` (cache is scoped to branch name by default), leading
to the consistent error `Elixir.Web.Mailer.NoopAdapter does not exist`
whenever a branch was pushed to more than once.
2. The same thing happens with the `integration_test-basic-flow` job
because the `api` service gets built after the `web` service in
docker-compose.yml, overwriting its cache
For some reason it seems the `APPLICATION_NAME` ARG is not busting the
Docker cache properly on GitHub actions for elixir container builds, so
the fix here was to [use
`scope=`](https://docs.docker.com/build/cache/backends/gha/#scope) to
segregate the cache layers between builds of the same branch.
This PR fixes a bunch of small things to allow a new flow to test
clients pinging a resource within docker compose.
Masquerade/Forwarding is enabled directly in the container for now, this
might change in the future.
Also added a README to be able to run this locally.
---------
Signed-off-by: Gabi <gabrielalejandro7@gmail.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
- Instead of having two, very similar jobs, we run our fmt, clippy and
tests steps across all crates and operating systems.
- We remove the dependency of the android and apple builds on the tests
and thus get faster feedback.
- We force clippy to fail on any warning. This one is super important
IMO. Warnings in Rust are very useful and ignoring them can lead to bugs
(think "unused Result" etc).
Resolves#1714.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Francesca Lovebloom <franlovebloom@gmail.com>
Stubs out the client app dirs and basic CI workflow for the client apps
in preparation to move them into this repository.
After this is merged @roop @pratikvelani you should be able to add the
client repos here.
Unfortunately, this doesn't seem to be stable. I don't really understand
why. Judging from the logs, the problem is not in the relay but somehow
the final UDP packet doesn't arrive at the `gateway` binary.
To not unnecessarily block other PRs, I am removing the check for now.
This makes it possible to build the Apple/Android FFI bridges and
integrate them with their respective client apps.
---------
Signed-off-by: Francesca Lovebloom <franlovebloom@gmail.com>
Co-authored-by: Roopesh Chander <roop@roopc.net>
This brindgs connlib from its own separated repo to firezone's monorepo.
On top of bringing connlib we also add and unify the Dockerfile for all
rust binaries and add a docker-compose that can run a headless client, a
relay and a gateway which eventually will test the whole flow between a
client and a resource. For this to work we also incorporated some elixir
scripts to generate portal tokens for those components.
Did some research when picking a package manager for the website and
settled on `pnpm` for the following reasons:
- CLI-compatible with `npm`
- Typically faster than even `yarn` especially on Apple silicon
- Security: Pnpm uses a different dependency resolution algorithm and
different folder structure of node_modules that prevents illegal access
to packages by other packages.
I think I caught all the places, but I may be missing something, so if
this isn't a good idea we can revert back.
This PR also cleans up the actions workflows to remove dead code.
* Remove `www/`
* Stub empty `website/` to silence Vercel. This shouldn't cause
conflicts when we merge `cloud` to `master`. Perhaps we want to start
working off `master` soon, and move the current tip of master to
`legacy`?
Targets specified in the `rust-toolchain.toml` file are automatically installed by `rustup`. This avoid setup steps for other devs and also simplifies the CI setup.
To be able to compile native code to musl, we do need `musl-gcc` which comes with the `musl-tools` package on ubuntu.
To complete the authentication scheme for the relay, we need to prompt
the client with a nonce when they send an unauthenticated request. The
semantic meaning of a nonce is opaque to the client. As a starting
point, we implement a count-based scheme. Each nonce is valid for 10
requests. After that, a request will be rejected with a 401 and the
client has to authenticate with a new nonce.
This scheme provides a basic form of replay-protection.
