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:
amd64for x86-64 andarm64for 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 withSKIP_ONEPASSWORD=1does not have it. - Service account token. Needs no desktop app. If the
opCLI is installed (at/usr/bin/op,/usr/local/bin/opor/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:
inotifylimit. 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 anIOException. SetDOTNET_USE_POLLING_FILE_WATCHER=1.- Unroutable IPv6. On a host whose IPv6 default route goes nowhere,
dotnet restorecan hang reachingapi.nuget.org, because NuGet's HTTP client tries v6 first. SetDOTNET_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.
Edit this page on the wiki Request support · Report vulnerabilities privately