cross-posted from: https://midwest.social/post/9890016
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.
You mean, they're mounting something that isn't an SD card to the /sdcard directory? Like something truly evil, such as
mount -t btrfs -o subvol=@home / /sdcard
? Or do you think there's not anything mounted there; it's just a directory in the root partition? None of that would make any sense.If they're letting whatever automount tool (eg udevil) do its thing, this is practically impossible. And if they know enough to do it by hand, I think they'd have answered the direct question of "which filesystem" with a filesystem rather than a mount point. Don't you think? We still don't know what filesystem they're working with, since they haven't answered the question.