FreeBSD native build workflow

[Borderliner]

I've added a FreeBSD native build workflow to github actions. It doesn't use cross-compilation and uses a native FreeBSD image directly so it's defined outside matrix.name. Build succeeds. It doesn't include run.sh file, so you might want to add that (I don't know how).

FreeBSD has been very susceptible due to not having Iran pkg servers. This is an attempt to bring FreeBSD online for Iranian users.

[therealaleph]

Reviewed via Anthropic Claude.

The FreeBSD use-case is real and the build approach (native VM via vmactions/freebsd-vm) looks right — FreeBSD cross-compile from Linux is painful enough that a real FreeBSD VM is the practical answer. Thanks for putting in the work.

Three changes I'd want before merging:

1. Triggers — restrict scope.
push: branches: [main] and pull_request: both run a FreeBSD VM build on every PR push (~10-15 min each). On a repo that gets 5-10 PRs/week, that's ~100 min/PR-cycle of GitHub Actions minutes for a build that's only consumed by FreeBSD users at release time. Tighter triggers:

on:
  workflow_dispatch:
  push:
    tags:
      - 'v*'

This way the FreeBSD build only runs on actual version tags (when there's something to ship to FreeBSD users), plus manual dispatch for testing.

2. Integration with release.yml's existing matrix.
The current .github/workflows/release.yml has a multi-target build matrix that uploads each artifact to the GitHub Release page (releases/{platform}-{tag}/). Right now your workflow uploads as a workflow-run artifact (ephemeral, falls off after 90 days, not visible on the Releases page). For FreeBSD users to actually find the build, it needs to land at:

releases/mhrv-rs-freebsd-amd64-vX.Y.Z.tar.gz

either by adding to release.yml's matrix (preferred — keeps everything in one pipeline), or by adding a gh release upload step to this workflow + a workflow_run trigger pointed at release.yml so it runs on release events.

I lean toward folding the FreeBSD job into release.yml as a sibling matrix entry — uses the same release-upload step the other platforms already share, and the FreeBSD-VM-on-Ubuntu-runner approach works just as well there.

3. The run.sh you mentioned.
The OpenWRT path in release.yml (mipsel-softfloat target) has a procd init script template instead of run.sh; FreeBSD might want an rc.d template similar to that. Or just ship the binaries and document the launcher separately in docs/. Either is fine — run.sh is mostly for desktop Linux convenience and not strictly required for cross-platform binary distribution.

Happy to land this if you can rebase against release.yml matrix integration (or keep the separate workflow but with the trigger fix at minimum + a gh release upload step). Either path is fine; the design discussion is worth having before the workflow goes live.

Re: the FreeBSD-pkg-server-blocked-from-Iran context — that's a useful angle and worth a note in the eventual docs/guide.md once we have FreeBSD binaries shipping. Mention it in the PR description or in a separate doc PR.

Leaving open. Will merge once one of the integration paths is chosen + implemented.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[Borderliner]

I tested the CLI binary in FreeBSD 15.0 and it actually works, but there are two solvable issues:

1. Certification detection doesn't work in FreeBSD. The ca.crt file needs to be copied to either /usr/share/certs/ or /usr/local/share/certs (the latter doesn't exist by default and has to be created). And then certctl rehash has to be run as root.
2. FreeBSD (or at least https://pkg.freebsd.org) doesn't accept ECDSA certificates but works with RSA certs. So I had to manually generate one with openssl command, put it inside ~/.config/mhrv-rs and replace the ca.crt file that the app creates itself. Then copy that ca.crt file into the folder I mentioned in part 1.

After these steps, the app works flawlessly. These changes are beyond my capabilities and require the admin/maintainer of the repo. But can confirm it 100% works and is fully useable. Though the UI binary has not been tested yet.

[therealaleph]

Thanks for putting this together — FreeBSD support is a worthwhile target.

I do not want to merge this workflow as-is yet, mainly because it would run on every pull_request and every push to main. The repo currently does not run full build CI on every PR; adding a native FreeBSD VM job to all PRs is a pretty large CI-cost/surface-area change.

Suggested safer shape:

1. Start with workflow_dispatch only, so maintainers can manually test FreeBSD builds without making every PR pay for a VM boot.
2. Add an explicit permissions block:

permissions:
  contents: read

3. If this becomes part of releases, wire it into the existing tag-driven release.yml artifact model rather than a separate push-to-main artifact workflow.
4. Consider pinning the third-party action more tightly than vmactions/freebsd-vm@v1 if we make it release-affecting.

So: good direction, but please narrow the trigger first. After that I am happy to rerun review.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[Borderliner]

@therealaleph Adding release binaries without adding certificate installation mechanism is not feature-complete and might not be a great idea. Currently cert installation happens in src/cert_installer.rs and the logic doesn't expect FreeBSD explicitly. It's a huge file and I'm unable/unwilling to add manual code. So your intervention is definitely required, since I don't have AI to provide a clean code and my internet access is very restricted to work further on this. Please see if you can provide this feature in next releases so my effort doesn't go to waste, I was able to compile it and test it and that's already a good amount of assurance.