The existence of alternate ... code signing standards would motivate

One possible "standard" here is the Git/Mercurial commit hashes themselves. A "validate signatures" hook could re-hash commits and verify that the hash is actually correct.

I'm not sure how possible it is for the hash to be incorrect. I can go mess with .git/objects/ and change the data for files or commits on disk so that the hash no longer matches the actual data, or rebuild git so that it the hash function has if (hash == A) { hash = B; } and then make a commit. When do git and hg detect that I did this?

The answer is probably "they detect it quickly and nothing bad happens", but the answer might be more subtle. There's a performance incentive to avoid revalidating the hash all the time. Attacks on the local working copy are not normally a major part of the security model. In T11537, we saw at least one case where Git validation was a tiny bit fast-and-loose (where porcelain commands forbid commits after 2099AD, but plumbing commands permit commits in 40,000 AD).

I suspect investigating this would reveal that both VCSes have reasonable implementations and mostly be a waste of time, but it's something we could at least consider in motivating this kind of hook.

See T8962, somewhat. When receiving inbound mail, we could decrypt PGP messages and verify PGP signatures.

If we opt not to verify PGP signatures, discarding them would be an improvement over the current behavior.

If we did this, it would be nice to allow the comment action dropdown to View Original Mail... or similar, and show the inbound mail with full headers and attachments. This could be useful forensically, and allow users to (conceivably) validate signatures themselves.

It's also generally bad to ninja-vanish attachments and not explain to the user what we did, and I don't think we can be 100% certain that an attachment is a PGP signature, although we can check that the content begins -----BEGIN PGP SIGNATURE----- and likely get relatively few false positives.

(Must Encrypt Mail is a magic meta-tag for testing the feature, not an organizational tag.)

This is sort of generically concerning to me:

https://news.ycombinator.com/item?id=20312826

Notably:

The OpenPGP specification puts no limitation on how many signatures can be attached to a certificate. The keyserver network handles certificates with up to about 150,000 signatures. GnuPG, on the other hand … doesn't. Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt. It doesn't stop, per se, but it gets wedged for so long it is for all intents and purposes completely unusable.
...
We've known for a decade this attack is possible. It's now here and it's devastating.
...
whoever did this [launched this attack] basically experimented on me (and Rob) directly ... if you get hit by a bus while crossing the street, I'll tell the driver everyone deserves a mulligan once in a while. You fool. You absolute, unmitigated, unadulterated, complete and utter, fool. Peace to everyone — including you, you son of a bitch.

This may only be a piece of the story, but, at face value, I think this reflects very poorly on GPG. I feel this (blaming attackers for launching attacks which have been in the wild for a decade) is generally not an appropriate attitude for a mature or technically competent project to have about security challenges.

It is also probably worth looking at and understanding the "Efail" vulnerability from last year (e.g. https://efail.de) before doing any implementation work here, although that looks more like "email is 60 years old" than like a specific PGP/GPG problem.

I am running through GPG for the first time:

$ gpg --gen-key

<... many many interactive prompts ...>

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 187 more bytes)

The process is now blocking forever. The accepted solution to this is apparently to open a second session, then run:

$ sudo apt-get install rng-tools
$ sudo rngd -r /dev/urandom

In practice, the sudo apt-get install rng-tools unstuck it.

All the garbage I typed is then not consumed by GPG and executed as shell commands.

This is, uh, quite an experience.