Add "frequently seen commentary"

Patatt hit a few news sources in the past few days, which resulted in
some expected commentary. Add some extra reasoning into the README that
would hopefully provide some answers to questions before they are asked.

Signed-off-by: Konstantin Ryabitsev <konstantin.ryabitsev@linux.dev>

1 files changed, 93 insertions, 0 deletions

diff --git a/README.rst b/README.rst
index 924b622..b751b68 100644
--- a/README.rst
+++ b/README.rst
@@ -400,3 +400,96 @@ Submissions must be made under the terms of the Linux Foundation
 certificate of contribution and should include a Signed-off-by: line.
 Please read the DCO file for full legal definition of what that implies.
 
+Frequently seen commentary
+--------------------------
+Why is this library even needed? Why not...
+
+Why not simply PGP-sign all patches?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+PGP-signing patches causes important problems for reviewers. If a patch
+is inline-signed, then this not only adds textual headers/footers, but
+adds additional escaping in the protected body, converting all '^-'
+sequences into '^- -', which corrupts patches.
+
+MIME-signing is better, but has several other downsides:
+
+- messages are now sent as multipart mime structures, which causes some
+  tooling to no longer properly handle the patch content
+- the signature attachments may be stripped/quarantined by email
+  gateways that don't properly recognize OpenPGP mime signatures
+- the From/Subject headers are rarely included into protected content,
+  even though they are crucial parts of what ends up going into a git
+  commit
+
+These considerations have resulted in many projects specifically
+requesting that patches should NOT be sent PGP-signed.
+
+Why not just rely on proper code review?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Code review is a crucial step of the development process and patatt does
+not aim to replace it. However, there are several areas where the
+process can be abused by malicious parties in the absence of end-to-end
+cryptographic attestation:
+
+1. A maintainer who struggles with code review volume may delegate parts
+   of their duties to a submaintainer. If that person submits aggregated
+   patch series to the maintainer after performing that work, there must
+   be a mechanism to ensure that none of the reviewed patches have been
+   modified between when they were reviewed by the trusted submaintainer
+   and when the upstream developer applies them to their tree. Up to
+   now, the only mechanism to ensure this was via signed pull requests
+   -- with patatt this is now also possible with regular patch series.
+
+2. It is important to ensure that what developer reviews is what
+   actually ends up being applied to their git tree. Linux development
+   process consists of collecting follow-up trailers (Tested-by,
+   Reviewed-by, etc), so various tooling exists to aggregate these
+   trailers and create the collated patch series containing all
+   follow-up tags (see b4, patchwork, etc). Patatt signing provides a
+   mechanism to ensure that what that developer reviewed and approved
+   and what they applied to their tree is the exact same code and hasn't
+   been maliciously modified in-between review and "git am" (e.g. by
+   archival services such as lore.kernel.org, mail hosting providers,
+   someone with access to the developer's inbox, etc).
+
+3. An attacker may attempt to impersonate a well-known developer by
+   submitting malicious code, perhaps with the hope that it receives
+   less scrutiny and is accepted without rigorous code review. Even if
+   this attempt is unsuccessful (and it most likely would be), this may
+   cause unnecessary reputation damage to the person being impersonated.
+   Cryptographic signatures (and lack thereof) will help the developer
+   quickly establish that the attack was performed without their
+   involvement.
+
+Why not just rely on DKIM?
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+DKIM standard is great, but there are several places where it falls a
+bit short when it comes to patch attestation:
+
+1. The signing is done by the mail gateways that may or may not be
+   properly checking that the "From:" header matches the identity of the
+   authenticated user. For example, a service that allows free account
+   registration may not check that alice@example.org sends outgoing
+   email with "bob@example.org" in the "From:" field, which would allow
+   Alice to impersonate Bob and have the messages arrive with a valid
+   DKIM signature.
+
+2. DKIM is usually seen as merely a spam reduction mechanism, so there's
+   usually little incentive for infrastructure administrators to be too
+   strict about how they handle the private keys used for DKIM signing.
+   Most likely, they are just stored on disk without a passphrase and
+   accessible by the SMTP daemon.
+
+3. DKIM's "relaxed" canonicalization standard for message bodies
+   replaces all multiple whitespace characters with a single space
+   before the body hash is signed. This poses significant problems for
+   patches where whitespace is syntactically significant (Python,
+   Makefiles, etc). A "return True" with a different indent will pass
+   DKIM signature check and may introduce a serious security
+   vulnerability.
+
+4. DKIM doesn't prevent typosquatting attacks. For example, an attacker
+   attempting to impersonate known.developer@companyname.com may send an
+   email from known.developer@company-name.com or any other
+   similar-looking address or domain, with valid DKIM signatures in
+   every case.