🔑 Update key for Beth Griggs

[BethGriggs]

I ran the CLI command and committed gpg/pubring.kbx and 4ED778F539E3634C779C87C6D7062848A1AB005C.asc. It also created gpg/tofu.db, is that to be ignored?

➜  release-keys git:(bethkey) ./cli.sh add 4ED778F539E3634C779C87C6D7062848A1AB005C
gpg: WARNING: unsafe permissions on homedir '/Users/bgriggs/release-keys/gpg'
gpg: key D7062848A1AB005C: "Beth Griggs <bgriggs@redhat.com>" 1 new user ID
gpg: key D7062848A1AB005C: "Beth Griggs <bgriggs@redhat.com>" 8 new signatures
gpg: Total number processed: 1
gpg:           new user IDs: 1
gpg:         new signatures: 8
keys.list <- 4ED778F539E3634C779C87C6D7062848A1AB005C
➜  release-keys git:(bethkey) ✗ git status
On branch bethkey
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   gpg/pubring.kbx
    modified:   keys/4ED778F539E3634C779C87C6D7062848A1AB005C.asc

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    gpg/tofu.db

[canterberry]

Maybe some folks more well versed in GPG internals can chime in, but from what I can tell, tofu.db is spurious, at least for the purpose of verifying signatures. That could probably be added to .gitignore.

[canterberry]

From https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html:

TOFU stands for Trust On First Use. In this trust model, the first time a key is seen, it is memorized. If later another key with a user id with the same email address is seen, both keys are marked as suspect. In that case, the next time either is used, a warning is displayed describing the conflict, why it might have occurred (either the user generated a new key and failed to cross sign the old and new keys, the key is forgery, or a man-in-the-middle attack is being attempted), and the user is prompted to manually confirm the validity of the key in question.

Because a potential attacker is able to control the email address and thereby circumvent the conflict detection algorithm by using an email address that is similar in appearance to a trusted email address, whenever a message is verified, statistics about the number of messages signed with the key are shown. In this way, a user can easily identify attacks using fake keys for regular correspondents.

When compared with the Web of Trust, TOFU offers significantly weaker security guarantees. In particular, TOFU only helps ensure consistency (that is, that the binding between a key and email address doesn’t change). A major advantage of TOFU is that it requires little maintenance to use correctly. To use the web of trust properly, you need to actively sign keys and mark users as trusted introducers. This is a time-consuming process and anecdotal evidence suggests that even security-conscious users rarely take the time to do this thoroughly and instead rely on an ad-hoc TOFU process.

In the TOFU model, policies are associated with bindings between keys and email addresses (which are extracted from user ids and normalized). There are five policies, which can be set manually using the --tofu-policy option. The default policy can be set using the --tofu-default-policy option.

The TOFU policies are: auto, good, unknown, bad and ask. The auto policy is used by default (unless overridden by --tofu-default-policy) and marks a binding as marginally trusted. The good, unknown and bad policies mark a binding as fully trusted, as having unknown trust or as having trust never, respectively. The unknown policy is useful for just using TOFU to detect conflicts, but to never assign positive trust to a binding. The final policy, ask prompts the user to indicate the binding’s trust. If batch mode is enabled (or input is inappropriate in the context), then the user is not prompted and the undefined trust level is returned.

The default trust model for GPG is pgp (Web of Trust), wherein TOFU has no effect. According to this doc, "TOFU offers significantly weaker security guarantees". Both PGP and TOFU are email-based trust models -- they're strategies for determining whether a given key actually belongs to the entity described by the user ID. This is useful for email signatures, but for the purposes of release verification, I'd posit that it's irrelevant, and gpg/tofu.db is safe to add to .gitignore.