ripasso reads a pass store with Rust and puts it behind a terminal interface

The root crate is a library, not the app you run

ripasso describes itself as a simple password manager written in Rust, but the more precise statement is in the README: the root crate ripasso is a library for accessing and decrypting passwords stored in pass format, meaning PGP encrypted files that are optionally kept in a git repository.

That splits the project in two layers that matter when you choose a package. The library handles reading the store, decrypting entries and exposing them. The applications are subcrates, and the Cargo workspace lists exactly three members: crates/ripasso, crates/ripasso-cursive and crates/ripasso-gtk.

So when a distribution asks whether you want the terminal version or the GTK version, that choice is about the front end, not about different password stores. The GitHub repository also has no GitHub releases, and the workspace version field reads 0.8.0, so the version you get comes from a distribution channel rather than from a tagged release on the project page.

The stated motivation is worth repeating because it explains the design. ripasso is a reimplementation of the gopass project in Rust, started mainly because the qml binding it depended on was unmaintained, and partly because writing password handling in a safe language seems like a good idea.

GPG is the foundation, and there are two crypto backends in the dependency list

The workspace dependencies make the architecture visible. Cryptography comes from two directions: gpgme at version 0.11 and sequoia-openpgp at version 2 with the crypto-openssl feature, plus sequoia-gpg-agent at 0.6 for talking to an agent. Supporting both a GPGME binding and Sequoia means the client can work with a system gpg installation through the library or with Sequoia's own implementation, and that choice is made by the user rather than baked in.

Around that sit the pieces a password store needs. git2 at 0.21 is present, which matches the pass convention of keeping the encrypted files in a git repository so that changes are versioned. tar and flate2 handle archive and compression operations, glob handles path matching, and config with toml handles configuration files. totp-rs at version 5 covers one time password entries, and arboard at 3 is the clipboard library, which matters because copying a secret into the clipboard is a normal step in a password workflow.

zeroize at version 1 is in the list too, and that is the dependency to pay attention to. Zeroing memory when a secret goes out of scope is a deliberate design choice for a credential tool, and its presence is a signal about the project's priorities rather than an implementation detail.

The cursive terminal interface is the one the author actually uses

Two user interfaces exist, and the README is candid about their relative maturity. The cursive interface is a TUI built on the cursive crate at version 0.21, it supports password age display and password editing, and the author states plainly: I use this as my daily password-manager.

The GTK interface is labeled WIP in the README heading itself. The documentation says it is not at feature parity with the cursive code base yet, but that basic operations work. The dependency list backs that split: the GTK crate pulls in gtk4 at 0.11, libadwaita at 0.9, glib at 0.22 and glib-build-tools, so it is a real desktop application built on the modern GNOME stack, and it also pulls in the locale_config and gettext crates for translations.

Two details about the release profile apply to every subcrate. The release profile sets lto to true, codegen-units to 1, strip to true and debug to false, which is what you would expect for a binary that handles secrets and is distributed through system package managers. And the workspace lints section turns clippy pedantic on as a warning level, so the lint bar for this codebase is set above the default.

Building the whole workspace, or one interface at a time

The README gives you two build commands and a pointer to a longer document. To build all user interfaces at once, the workspace root is enough:

cargo build --all

To build a single interface, the package flag selects it, and the cursive terminal client is built with:

cargo build -p ripasso-cursive

The GTK build is the same command with the other package name. The detailed build procedure, including the system dependencies GTK and GPG need, is not in the README but in BUILD_INSTRUCTIONS.md in the repository.

The repository also carries flake.nix and flake.lock, so a Nix build is a first class path, and generate_pot.sh plus TRANSLATIONS.md document the gettext translation workflow, with the gettext crate in the dependency list to back it. The rust-version field is set to 1.91 and the edition to 2024, so the toolchain requirement is recent and specific, which is another reason the Nix flake and the distribution packages are the practical route for most users.

Install paths run from Arch to Alpine, with Fedora needing a Copr

The distribution coverage is broad, and the install methods differ enough to be worth listing. On Arch the terminal interface is a single command:

pacman -S ripasso

On Fedora the Copr repository has to be enabled first:

sudo dnf copr enable atim/ripasso -y

After that the terminal version and the unstable GTK version are separate packages:

sudo dnf install ripasso

sudo dnf install ripasso-gtk

Nix users, including the ones on Mac OS X where the README calls the nix package system the best way to install ripasso right now, install the terminal interface by attribute:

nix-env -iA nixpkgs.ripasso-cursive

Alpine is the one that needs a repository change first, since ripasso-cursive is currently in the testing repository for apk, so the testing repository has to be added to the apk repositories file before the package will resolve:

apk add ripasso-cursive

The pattern across all of them is that the terminal interface is packaged and stable, while the GTK interface is either marked unstable or absent.

Where ripasso is the wrong choice

The most obvious limitation is not technical but positional. The GTK interface is still work in progress and is not at feature parity with the terminal code base, so anyone who wants a desktop application with the full set of operations is signing up for a moving target. The README is honest about this, but a user reading it may not appreciate that the two interfaces are not interchangeable.

The second limitation is that ripasso speaks pass format and nothing else. The library accesses and decrypts passwords stored as PGP encrypted files, optionally in a git repository. If your passwords live in a browser's encrypted profile, in a proprietary password database, or in a Bitwarden style cloud vault, this project has no import path for them that the README describes. Its value is highest for people who already have a pass store and want a client for it.

The third is the pace of releases. There are no GitHub releases on the repository, so there is no tagged stream to pin in a deployment script, and the last push was on 2026-09-14. The code moves, but the versioning story a packaging system gives you depends on the distribution channel rather than on the project page. The README does not document a release process, a changelog or an upgrade procedure, and it does not say what happens to a store when the format changes.

Licensing, licensing of the front ends, and who should switch

ripasso is licensed GPL-3.0-only, and the Cargo workspace repeats that as the license field for every crate. The LICENSE file is named LICENCE in the repository root, and the authorship is listed as Joakim Lundborg and Alexander Kjäll. For a credential tool, GPL-3.0 is a reasonable choice because it guarantees that derived versions stay open, and it means anyone who patches the library has to publish the patched source.

Switching from gopass to ripasso is the obvious comparison the project itself invites, since ripasso is the Rust reimplementation of gopass. The difference in approach is the same one that moved the project: gopass is Python with a qml based desktop interface whose binding was unmaintained, while ripasso keeps the pass store semantics and swaps the implementation for Rust with a terminal client that is feature complete and a GTK client that is not yet there. For a user who works from a shell, the cursive interface is the closer replacement today.

The practical test for a team is short. If your passwords are already in a pass format store and your people are comfortable in a terminal, ripasso is a good fit and the install paths above cover every major Linux distribution. If you need a finished desktop client, a browser extension or an import from another manager, the WIP status of ripasso-gtk is the reason to wait. Whichever way you go, verify first that gpg works on your machines, since the client is a reader and decryptor for a store that your existing gpg setup owns.

Editorial conclusion

ripasso fits users who already keep their passwords in a pass format store and want a Rust client with a usable terminal interface, and it does not fit someone who wants a finished desktop password manager or a browser integration, since the GTK interface is explicitly not at feature parity; before adopting it, check that your store's GPG setup works with the sequoia and gpgme backends the workspace depends on and verify which subcrate you actually need, since the root crate is a library.

Frequently asked questions

Official sources

1. cortex/ripasso on GitHub
2. Issues
3. License: GPL-3.0
4. README