> Date: Sat, 6 Aug 2022 18:47:47 -0400 > From: Gabriel Rosenkoetter <g...@eclipsed.net> > > I mostly use macOS at home and Windows at work in that "desktop" context > these days, so I threw up my hands a few years ago and wrote my own > credential manager whose datastore is a USB mass storage device attached > to my keychain, and is largely a UI wrapper around a PGP-encrypted file > in a specific format. (I prefer USB devices that either have hardware > encryption or are formatted with an encrypted file system, but whatever.)
To be clear, fidocrypt(1) is not a general-purpose credential manager. A fidocrypt file on disk stores a _single_ secret, which can be opened by any one of the U2F/FIDO devices registered with the file. That secret might be used to unlock a general-purpose credential manager, or a cgd(4) volume (e.g., your USB mass storage device), so that when they're locked you need the U2F/FIDO device (or some other backup of the secret) to unlock them. > But that's a bunch of home-rolled garbage, whereas I think what you're > proposing to add to base is an interface to a standards-compliant (and > somewhat-open) device specification. Right? The _file format_ used by fidocrypt(1) is bespoke, based on sqlite3. The _protocol_ fidocrypt(1) uses to talk to U2F/FIDO devices is standard, and is the same as you can use with web browsers in webauthn for securing things like Twitter and Gmail accounts against phishing. The same U2F/FIDO device can be safely reused for both purposes. > I guess my follow-up Devil's advocacy question would be: why does this > need to be in base, rather than provided via ports? cgdconfig runs early at boot before most file systems are mounted -- often before the file systems on which any packages are installed are mounted. The cgdroot ramdisk, for instance, has a very minimal NetBSD userland in a ramdisk just to configure cgd(4) volumes before mounting the `real' root from them and chrooting into it. fidocrypt could be baked into this ramdisk.