Rook, a secret service backed by Keepass 4.x kdbx
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.
I agree. I just fell like there were still places they could have gone with it. Apparently, even with promotions. Getting a half pip, or even a full one, doesn't necessarily automatically get you out of lower decks... and how fast do promotions come? Once every year or two - no faster, certainly.
And if we can have shows about the bridge crew, and shows about lower decks, we could certainly have shows about the in-between strata. An (original) Enterprise class had a crew of CA 400 people. Most of this didn't spend any time on the bridge; bridge crew was, what, 3 dozen people, max? The Ceritos is a California class; I've seen estimates of a crew compliment of 160. If we assume a max of 40 bridge crew (on rotation, with alternates), that leaves 120 people in other categories. Plenty of room for new assignments, duties, experiences; hell, except for re-assignments to other ships, they could drag the show out indefinitely. The bridge crew characters would take the most attrition.