* First, decide that for some reason the standard pass password manager is
  unacceptable. One reason may be the risk of compromise or bad commits
  (by a hostile actor). Another may be matadata leakage: pass stores the
  name of the (username, password) pair in plaintext.
  + Regarding the latter, my ccrypt-based solution is better than that, and
    it immediately struck me as a bad point. Was already thinking about what
    I would do, and it involved sqlite with all fields except for time stamps
    encrypted.

* Using sqlite (sqlite3) and one of {Kotlin, Golang, Swift} (in rough order
  of likelihood) would probably be the way to go.
* Use a table of the following form to store the passwords (call it passwords):
  id integer not null primary key
  name blob
  username blob
  password blob
  notes blob (can be null)
  created integer
  modified integer
  accessed  (read) integer
  + id will be the low 64 bits of the MD5 hash of the encrypted name
    case-folded to lowercase (encrypt with a zero IV, don't prepend).
  + all blobs will be AES-encrypted with prepended IV, a'la EncryptedProperties.
  + timestamps are seconds or milliseconds since the epoch
* Use four other tables to store configuration parameters (as needed)
  integers, reals, strings, blobs.
  + Each will have an implicit rowid field, a string name field, and a
    value field of type integer, real, text, or blob as appropriate.
  + Probably only put those in the schema on an as-needed basis, i.e.
    a reals table will only exist if we have configuration parameters
* Four major subcommands: create, read, update, delete.
  + Error to create a password whose name (case insensitive) already exists.
  + Error to read, update, or delete one whose name does not exist.
  + Read should support a --like option to do inexact matching. If one
    match, act much like read w/o --like. If multiple matches, just list
    the names.
  + Read should also support a --clip option that deposits the password
    into the clipboard without printing it.
  + Read should also support a --verbose or --long option that causes a
    stanza-like, key: value dump of the full record. If --clip is used
    along with --verbose, password prints as "(in clipboard)"

* Use same password everywhere.
  + Use a dummy config param to ensure correct password (attempt decrypt of
    it first, write it base64'ed).
  + Could theoretically use different p/w's for different rows, but causes
    headaches matching names later, so avoid.

* Misc:
  + Include a password generator along the lines of genpass.
    - This should be as a --generate option to the create and update
      subcommands.
    - --generate allows four other options: --length, --symbols, --clip,
      --verbose.
    - Default length should be 12 (default no symbols).
    - If --clip supplied, copy new password to clipboard.
    - If --verbose supplied, print new password.
    - Default to be silent and not put password in clipboard, just change
      in database.
  + Command-line only, no GUI.
  + JSON for import subcommand (if we implement):
    https://javaee.github.io/jsonp/getting-started.html