Workflows Archive on
 help / color / Atom feed
From: "Jason A. Donenfeld" <>
Subject: Re: Patch attestation RFC + proof of concept
Date: Fri, 28 Feb 2020 10:30:23 +0800
Message-ID: <> (raw)
In-Reply-To: <>

Some constructive suggestions that might address some (but not all!)
maliability concerns and some clunkiness concerns:

A. What data are you signing?

Your current approach is to split up the email into parts, canonicalize
them, hash them, and then sign those hashes. Instead you could actually
more easily canonicalize the applied email. That is: when you have a
commit in a git tree, you can always git-format-patch it into the same
format. So, if you git-am an email, and then git-format-patch it out,
you'll get some standard format. You could insist all signatures are
made over this standard format. There's still the same set of attacks I
mentioned earlier here, but it's a bit less frail.

B. How are you communicating the signatures?

Your approach sticks these on a separate mailing list, linked by some
hash prefixes. Two approaches that would make the whole thing a lot less

1. Include it as a separate part in a multi-part mime message. Lore web
interface could bury it someplace reasonable. vger could learn to accept
these parts, and since hashing is already mega fast, it could even
validate that the hashes are correct and reject emails with bad (or
missing) hashes. (I'm not suggesting validating the signature, but
rather just the hashes.)

2. Switch to using the tiny ed25519 signatures provided by
signify/minisign -- which has numerous benefits over gpg alone -- and
stick it in the mail headers. This is something git-send-email could
learn to add.

X-Git-Format-Patch-Hash: aC1ywMbaJpiMFJY7vK/62eBKtrgKiVIXFHa+WPQwBJk=
X-Git-Format-Patch-Ed25519-Signature: aSscBu2pXbIEDCuRZ7E0uKWVsE5SitNM8UA44tuFc/rg3GQwv5Ur/mpOk2mQJbT6dPDghuxJ1gwZKAZK20BXAQ==

I prefer (2), but (1) would be acceptable if you're some how wedded to
pgp and I can't talk you out of it. I can write whatever cryptographic
code we need to do (2), but I suspect signify/minisign have everything
we need.

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 17:25 Konstantin Ryabitsev
2020-02-26 17:50 ` Kees Cook
2020-02-26 18:47   ` Konstantin Ryabitsev
2020-02-26 20:11 ` Jason Gunthorpe
2020-02-26 20:42   ` Konstantin Ryabitsev
2020-02-26 21:04     ` Jason Gunthorpe
2020-02-26 21:18       ` Konstantin Ryabitsev
2020-02-27  1:23         ` Jason Gunthorpe
2020-02-27  4:11 ` Jason A. Donenfeld
2020-02-27 10:05   ` Geert Uytterhoeven
2020-02-27 13:30     ` Jason A. Donenfeld
2020-02-27 14:29   ` Konstantin Ryabitsev
2020-02-28  1:57     ` Jason A. Donenfeld
2020-02-28  2:30       ` Jason A. Donenfeld [this message]
2020-02-28 18:33         ` Konstantin Ryabitsev
2020-02-28 17:54       ` Konstantin Ryabitsev
2020-03-06 16:53       ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Workflows Archive on

Archives are clonable:
	git clone --mirror workflows/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 workflows workflows/ \
	public-inbox-index workflows

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone