Page MenuHomePhabricator

Consider supporting GPG/PGP
Open, LowPublic


PGP has three relevant interaction points with Phabricator:

  • See PHI764. When sending "Must Encrypt" email, we could encrypt it and send the actual mail content instead of a simple link to the web UI.
  • See T8962, somewhat. When receiving inbound mail, we could decrypt PGP messages and verify PGP signatures.
  • Git supports PGP signing, and we could verify PGP signatures on commits.

All three use cases are fairly niche and relatively low-value, so it's likely that there are two possible futures here based mostly on how much of a mess PGP is:

  • If PGP validation, encryption, and decryption are reasonably easy to implement and verify these features likely make sense to bring upstream. There's at least some interest from users, including customer interest in PHI764.
  • If PGP is a giant mess that no normal person can hope to understand without first compiling Gentoo nine times, the value of these features is probably not worth their overhead.

The existence of alternate mail encryption, mail signing, or code signing standards would motivate exposing these as modular hooks. However, I'm not aware of any real alternatives to PGP in any of these areas. If more reasonable alternatives existed, we could provide hooks and leave PGP to third parties who are great at compiling Gentoo, but I'm hesitant to add the hooks if we have zero upstream implementations.

The next step here is to evaluate PGP:

  • How difficult is encrypting mail with PGP?
  • How difficult is decrypting and verifying PGP mail?
  • How difficult is verifying Git commit signatures?
  • Can we do this stuff in PHP, or do we need to depend on an external?
  • Would the interface for adding PGP keys look mostly like the interface for adding SSH keys, or are there additional considerations?
  • As a normal user, how hard is configuring PGP mail?
  • As a normal user, how hard is configuring PGP in Git?

If the answers here are mostly "it's pretty straightforward", we can add hooks and PGP support.

If the answers here are mostly "compile Gentoo nine times", this may be a dead end, at least for now.

Event Timeline

epriestley created this task.

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:


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. 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.