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 triaged this task as Low priority.

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.

epriestley updated the task description. (Show Details)Jan 2 2019, 4:16 PM

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

amarin added a subscriber: amarin.Feb 11 2019, 1:13 PM
epriestley moved this task from Backlog to Far Future on the Diffusion board.Apr 15 2019, 3:59 PM