rook: A secret service tool backed by a KeePass v4 database
sr.ht

Howdy Lemmy,

I’m announcing Rook v0.0.9, software that provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass 4.x kdbx file.

The problem Rook solves is mainly in script automation, where you have aerc, offlineimap, isync, vdirsyncer, msmtp, restic, or any other cron jobs that need passwords and which are often configured to fetch these passwords from a secret service with a CLI tool. Unlike existing solutions, Rook is headless and does not have a bespoke secrets database, full of passwords that must be manually synchronized with Keepass; instead, it uses a Keepass db directly.

While the readme goes into more detail, I will say the motivation for Rook evolved from a desire to use a Keepass db in a GUI-less environment and finding no existing solutions. KeepassXC provides a secret service, but is not headless; it also provides a CLI tool, but this requires the db credentials on every call. kpmenu exists, but is designed specifically to require human interaction and is unsuitable for cron environment scripting. Every other solution maintains its own DB back end, incompatible with Keepass.

Rook also benefits from minimal external dependencies, and at 1kloc is auditable by developers - I believe even by ones who do not know Go (the language of implementation). Being able to verify for yourself that there’s no malicious code is a critical trait for a tool with which you’re trusting secrets.

Rook is fit for purpose, and signed binaries are provided as well as build-from-source instructions (for auditors).

The project contains work in progress: credentials are limited to simple password-locked kdbx, and so doesn’t yet support key files. Bash scripts that provide autotyping and attribute/secret selection via rofi, fzf, and xdotool are provided, for GUI environments; these have known bugs. Rook has not been tested on BSD, Darwin, or any other system than Linux, but may well work; the main sticking point is the use of a local file socket for client/server communication, so POSIX systems should be fine, but still, YMMV.

As a final caveat: up until v0.0.9 I’ve been compressing with brotli, which is very nice yet somewhat obscure. With the next release, everything will be gzipped. Also included in the next release will be packages for various distributions.

  • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍OP
    1·
    10 个月前

    Interesting use case. For your use case, is there a reason you’re not using pass (or the more self-contained but compatible gopass)?

    What you’re suggesting wouldn’t be difficult; it’d be a sort of ratchet where the password is encrypted and passed through, and then decrypted by Rook. You’d still need to supply Rook with the decryption key, which gets you back to just prompting again.

    But I see the plight: you might be using Vault and needing to start Rook with credentials. You can’t use -P, because it’s interactive; you don’t want to use 12-Factor, because it exposes passwords.

    Would an acceptable solution be if Rook accepted the password on stdin? I intend to implement the key file authentication mechanism, which might also be a solution for your use case.