Linux build

Linux build

Experimental. Since 5.0.0 RavensPort uses Avalonia instead of WPF and ships a Debian/Ubuntu package. Since 5.0.1 there are two packages: amd64 for x86-64 and arm64 for 64-bit Arm, which includes a Raspberry Pi running 64-bit Raspberry Pi OS. Windows is still the supported target: the Microsoft Store package and the approval suite are Windows-only. CI builds, installs and tests the Linux packages on every pull request, on both architectures, but they have had far less use. Treat the Linux build as something to try rather than something to depend on, and report what breaks.

What is different from Windows

The proxy, funnels, API to MCP bridges, OAuth flows and proxy keys are the same code and behave the same. What differs is everything that touches the desktop:

	Windows	Linux (Debian/Ubuntu)
Proton Pass session key	Sealed by a Windows Hello gesture	Held in the desktop keyring through libsecret
1Password, desktop app	In-process SDK	In-process SDK (libonepassword.so)
Tray icon	Themed menu, balloon notifications	The desktop's own tray; menu is not themed, no balloon
mTLS client certificates	Supported	Same code; its unit tests run in the Linux CI job, but it has had little use by hand
Which pass-cli / op it will run	Must be signed by Proton / 1Password	Must be installed by an administrator — see below

The keyring is a weaker promise than Hello. The keyring encrypts the key at rest, so reading the disk does not reveal it, but it is unlocked with your login and normally stays unlocked — any process running as you can ask for the key back without a prompt.

Install

From the RavensPort apt repository, so apt upgrade keeps it current. apt picks the package for your architecture:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://abishekvupputur.github.io/ravensPort/apt/ravensport.asc \
  | sudo tee /etc/apt/keyrings/ravensport.asc > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/ravensport.asc] https://abishekvupputur.github.io/ravensPort/apt ./" \
  | sudo tee /etc/apt/sources.list.d/ravensport.list
sudo apt update
sudo apt install ravensport

Or download ravensport_<version>_amd64.deb or ravensport_<version>_arm64.deb from the Releases page and install it with apt rather than dpkg -i, so the dependencies are resolved instead of merely reported:

sudo apt install ./ravensport_5.0.1_arm64.deb

Depends	libx11-6, libice6, libsm6, libfontconfig1, libsecret-1-0
Recommends	gnome-keyring — without a running keyring there is nowhere to keep a Proton Pass session key
Installs to	/opt/ravensport, a ravensport command on PATH, and a desktop entry

Start it from your launcher or with ravensport. From there it is the same as on Windows: the setup page opens, and the proxy starts once a vault is connected (http://127.0.0.1:5559 by default).

Build the package

You need the .NET 10 SDK, Go (the version in src/OnePasswordNative/go.mod) with a C compiler for cgo, and dpkg-dev:

sudo apt install -y build-essential dpkg-dev
git clone https://github.com/abishekvupputur/ravensPort.git
cd ravensPort
packaging/build-deb.sh            # or: packaging/build-deb.sh 5.0.1

That writes packaging/ravensport_<version>_<arch>.deb for the machine it runs on, amd64 or arm64. It does not cross-compile: build on an arm64 machine to get an arm64 package. The package is self-contained, so the .NET runtime travels inside it, and it builds libonepassword.so from the same Go source as the Windows DLL.

No Go toolchain? SKIP_ONEPASSWORD=1 packaging/build-deb.sh builds without it. The package then has no 1Password backend (Proton Pass still works), so it is for trying the app, not for releasing. Without the variable the script stops with a message if Go is missing.

Building leaves your checkout as it found it: the script restores the packages.lock.json files it would otherwise change, so a build never dirties the tree.

Connect a password manager

Proton Pass

Sign-in runs the Proton Pass CLI, pass-cli, which you install yourself; RavensPort installs nothing. Because the session key is handed to that program, RavensPort only runs a copy it can trust: one in a system location (/usr/bin, /usr/local/bin, /opt, /snap/bin and similar), owned by root, and not writable by anyone else — nor any directory above it.

A pass-cli in ~/.local/bin is therefore refused, whatever its permissions, because any program running as you could have put it there. If you downloaded the binary yourself, install it where RavensPort will accept it:

sudo install -m 755 ~/.local/bin/pass-cli /usr/local/bin/pass-cli

then press Check again on the setup page. RavensPort finds it by itself; no environment variable is needed.

For a self-built or portable copy you would rather not move, set RAVENSPORT_PASSCLI_PATH to its path. That is honoured as your explicit choice, unchecked, and it has to be in the environment the app starts from — a launcher-started app will not see a variable exported in one terminal.

1Password

Two ways in, both on the setup page:

• 1Password desktop app. Install the 1Password app for Linux and, in it, open Settings → Developer and turn on Integrate with other apps. That channel is opened when 1Password starts, so switch it on and then restart 1Password before pressing Connect to 1Password. Enter the account name exactly as it appears at the top of the sidebar. This path uses the bundled libonepassword.so, which talks to the desktop app; a package built with SKIP_ONEPASSWORD=1 does not have it.
• Service account token. Needs no desktop app. If the op CLI is installed (at /usr/bin/op, /usr/local/bin/op or /snap/bin/op) RavensPort prefers it, so the token lives in a child process that exits; without it the token is used through the in-process library.

Known rough edges

• Tray. Tray support varies across Linux desktops, and this app is tray-resident by design. GNOME needs an extension for a tray icon to exist at all. Without one, start the app from the launcher and use the window.
• Second launch. The activity log may record Could not listen for a second launch: the mechanism that focuses the running window when you start a second copy is not supported on Linux. The app runs normally; a second launch simply does not bring the first to the front.

Building and testing on Linux

dotnet restore RavensPort.slnx --locked-mode
dotnet build src/RavensPort.App/RavensPort.App.csproj -c Release --no-restore
dotnet test tests/RavensPort.Core.Tests -f net10.0 --no-restore
dotnet test tests/RavensPort.UI.Tests -f net10.0 --no-restore

Two environment quirks that are about the host, not the code:

• inotify limit. Each test host starts a file watcher, and a default limit of 128 instances is quickly exhausted, failing well over a hundred proxy tests with an IOException. Set DOTNET_USE_POLLING_FILE_WATCHER=1.
• Unroutable IPv6. On a host whose IPv6 default route goes nowhere, dotnet restore can hang reaching api.nuget.org, because NuGet's HTTP client tries v6 first. Set DOTNET_SYSTEM_NET_DISABLEIPV6=1.

--locked-mode matters: the lock files are shared with the Windows build and record both target frameworks, so a restore that adds a runtime identifier to them will fail CI with NU1004.

Uninstall

sudo apt remove ravensport     # the program
sudo apt purge ravensport      # the same, plus any packaged configuration

Neither touches your own data, because none of it belongs to the package — it is written at run time under your home directory. To be rid of it as well:

rm -rf ~/.config/RavensPort ~/.local/share/RavensPort

That is the activity log (~/.config/RavensPort/logs/) and the local settings and manifests (~/.local/share/RavensPort/). The Proton Pass session key is in the desktop keyring rather than in either directory, and is dropped by Disconnect or by signing out on the Settings tab.

Deleting all of it removes nothing from your password manager: every credential, route and funnel lives in the vault, so reconnecting the same vault on any machine brings the whole configuration back.

---