lsPass — local, encrypted password manager

GTK4 / gtkmm-4 · C++23 · CMake · SQLite · libsodium

lsPass stores logins, secure notes and API keys in a local encrypted vault. No network, no cloud, no telemetry. Nothing secret is ever written to disk in plaintext.

Build & test

sudo apt install libgtkmm-4.0-dev libsqlite3-dev libsodium-dev nlohmann-json3-dev
cmake -B build
cmake --build build -j
ctest --test-dir build --output-on-failure   # 41 unit tests
./build/lspass

The vault lives at ~/.local/share/lspass/vault.db (permissions 0600).

Debian/Ubuntu package

cmake -B build-rel -DCMAKE_BUILD_TYPE=Release
cmake --build build-rel -j
cd build-rel && cpack -G DEB        # requires: dpkg-dev, file
sudo dpkg -i ../packages/deb/lspass_1.0.0_amd64.deb

The .deb lands in packages/deb/ and ships the binary, a com.lspass.App.desktop launcher entry, and the app icon (packaging/com.lspass.App.svg, installed into the hicolor theme).

cmake --install without CPack uses the default /usr/local prefix. Runtime dependencies (libgtkmm-4.0, libsodium, libsqlite3, …) are resolved automatically by dpkg-shlibdeps, so apt --fix-broken install or sudo apt install ./lspass_1.0.0_amd64.deb pulls in everything needed.

Security design (researched best practices)

Based on the OWASP Password Storage Cheat Sheet, the libsodium documentation, and the envelope-encryption pattern used by established password managers (Bitwarden, KeePassXC-style key wrapping):

master password
      │  Argon2id  (memory-hard KDF, random 128-bit salt,
      ▼            opslimit/memlimit = libsodium "moderate",
    KEK (32 B)     parameters stored in vault for future upgrades)
      │  XChaCha20-Poly1305 (key wrap)
      ▼
    DEK (32 B, random)  ── wraps nothing else, RAM only, never on disk
      │  XChaCha20-Poly1305 AEAD per field
      ▼
SQLite: entries(title, username, url [plaintext metadata],
                secret, notes [sealed blobs: nonce‖ct‖poly1305 tag])

Why these choices:

Honest trade-off: title, username and url are stored as plaintext so the list/search works without decrypting every row. The secrets themselves (passwords, notes, API keys) are always sealed blobs. The unit test secrets_not_stored_in_plaintext byte-scans the vault file (incl. WAL) for a canary secret to prove this.

Testing

ctest runs three suites (41 cases) against the GUI-independent core library. The whole suite is also run under AddressSanitizer + UBSan:

cmake -B build-san -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined" \
      -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address,undefined"
cmake --build build-san -j && ctest --test-dir build-san

Release builds add -fstack-protector-strong, -D_FORTIFY_SOURCE=2, PIE and full RELRO (-Wl,-z,relro,-z,now).

• crypto — AEAD round-trips, empty plaintext, truncated-blob rejection, wrong-key/tamper/AAD-mismatch rejection, nonce uniqueness, KDF determinism, salt & unicode-password handling, key wrap/unwrap, constant-time compare edge cases.
• vault — create/reopen, wrong-password rejection, CRUD, persistence, unicode + 100 KiB secrets, invalid-ID handling, no-plaintext canary scan, search, settings persistence, master-password change, tampered entry/header detection, corrupted KDF-parameter rejection.
• generator — length/charset guarantees incl. boundary lengths, class coverage, uniqueness, entropy estimate, passphrase format/bounds, invalid-option handling.

Layout

src/core/crypto.{hpp,cpp}     SecureBytes, Argon2id KDF, XChaCha20-Poly1305, key wrap
src/core/vault.{hpp,cpp}      SQLite vault, envelope encryption, CRUD
src/core/generator.{hpp,cpp}  CSPRNG password/passphrase generator
src/ui/                       gtkmm-4 UI (unlock screen, list, editor dialogs)
tests/                        ctest suites (no external framework needed)

License

MIT — see LICENSE.