Closes#7008.
We already signed the GUI exe and the entire MSI package, but when
adding the IPC service we overlooked that one.
This PR:
- Modifies the signing script to accept multiple EXEs
- Modifies the Tauri bundle command to sign both exes
- Updates the changelog
Adds a sanity check to prevent clobbering assets on published releases.
Otherwise, assets will continue to be pushed to the published release
until the version is bumped.
```[tasklist]
### Before merging
- [x] Make sure the service auto-starts
- [x] Make the process idle and report its status to Windows properly using https://github.com/mullvad/windows-service-rs
- [x] DRY log dir code
- [x] Figure out where service logs will go and how the GUI will zip them
- [x] Make sure the service gets a shut down signal from Windows (this is hard to catch in the Tauri GUI)
- [x] Make sure the service restarts when Firezone is updated
- [x] Make sure the service is stopped and un-installed when Firezone is un-installed
- [x] Add test to install the MSI and check that the service runs
- [x] (will move to another PR) ~~Clean up function names~~
- [x] Make sure the Linux GUI was not broken by refactoring
```
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] (FAILED) Test CI deb on Ubuntu 24.04 #4883
- [x] Wait for everything else to merge: #3884
- [x] Fix#4889
- [x] Fix#4890
- [x] Test on Ubuntu 20.04 (683bddc0b passed)
- [x] Test on Ubuntu 22.04 (683bddc0b passed)
- [x] diff between main and 683bddc0b to make sure nothing in the code changed
- [ ] Someone other than me should give it a once-over. `intended_behavior.md` has the manual smoke test I've been doing on it. Install script is <a943a9dba1/scripts/firezone-client-gui-install.sh> Deb package from CI is <https://github.com/firezone/firezone/actions/runs/8972824465/artifacts/1477261361>
```
This aligns some of the internal names with #4531, but it shouldn't
break the externally-visible things like package names or permalinks.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
```[tasklist]
- [x] Update website
- [x] Update blog entry with old link
- [ ] ~~Replace Github URL in GUI Client updater with our own links~~
- [ ] Wait for CI to go green
```
Refs #4531
This proposes a unified scheme for deb and MSI packages, and moves
Windows to that scheme.
This breaks compatibility. Existing Clients won't recognize the new
asset names once this is merged, so they won't show the "Firezone 1.0.0
is available" pop-up.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Refs #3713
With this, the deb package for the Linux GUI Client contains a build of
the Linux CLI Client, at `/usr/bin/firezone-client-tunnel`. Future PRs
can add IPC to the code.
There is also a Windows stub, since Windows will eventually need a
tunnel process and a CLI Client.
In the future we might need to move or rename things, since the CLI
Clients and tunnel binaries for both Linux and Windows may all share
code or at least architecture. For now there is a slight duplication
with this being built as both "Firezone Client Tunnnel" and "Firezone
Linux Client"
Refs #3713
```[tasklist]
### Before merging
- [ ] Is 'firezone-client-tunnel' okay for the binary name?
- [ ] Using a library and building it as two binaries is correct, right? `cargo run -p firezone-client-tunnel` takes 1 second. `cargo run -p firezone-gui-client --bin firezone-client-tunnel` takes 1m42s because it builds all the GUI deps.
```
I thought this was going to use `cargo-deb` but it was actually easy
with the Tauri deb bundling we already use.
```[tasklist]
### Before merging
- [x] Make sure every file in the Tauri deb is also in our deb (e.g. icons)
```
AppImages won't work with process splitting. (#3713)
As far as I can tell, they just produce one binary. Internally they use
FUSE or something to mount a squashfs image, but that image won't be
able to hook into systemd and run with root permissions and everything.
I don't think it's practical, and Tauri's AppImage bundling doesn't have
the features for it.
Even their deb bundler doesn't have any way to specify a path for a
daemon to be installed. The sidecar feature only seems intended for the
GUI app to call, not anything else on the system.
(There is such a thing as installing AppImages, but I don't think it's
worth pursuing - We should just do debs)
Refs #3230
It looks like we need to sign the internal exe before it gets bundled
too. We can use `beforeBundleCommand` to do so.
Soon, Tauri should have native support for this exact scenario:
https://github.com/tauri-apps/tauri/pull/8718
