Re: [openpgp] review of the SOP draft

Daniel Kahn Gillmor <> Sun, 17 November 2019 10:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0011120059 for <>; Sun, 17 Nov 2019 02:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=2o7jfctq; dkim=pass (2048-bit key) header.b=34LPZJnz
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NwHcWFCizCXR for <>; Sun, 17 Nov 2019 02:41:40 -0800 (PST)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1714012004D for <>; Sun, 17 Nov 2019 02:41:40 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1573987299; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dhDjSldOuNTf8RgZ8uH8SjXa6VgAHw5D+DA9Tpq7toU=; b=2o7jfctqnXwZv+jhxX4avl0zQGEVQ2TK8W9d7FMNtW/46FQj+3Awy6F1 2dLHcMk/XmWLSc8etAau5k0YidPnDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1573987299; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dhDjSldOuNTf8RgZ8uH8SjXa6VgAHw5D+DA9Tpq7toU=; b=34LPZJnz9gtKRrQtMQG1bzvikpFU8F7gEVGOV4ZuI9/6O55ES9RZS6nC DwXOdfXv2WJ7majxOuBcupsI0c1iKyr+Dqzue/F6Lpx6tZz7yjeDaV47q1 6FVmeu9RbtltD6edORk5LlN71zQvkkuPRqbUtac/m+jNbhNDhf2el9uhde mjXoXozoyWQBThyOKtUe004qRC0ZLQuAwY50c3ZTLXRorR+keun/mkjWLB CMw//My0u6t04Ow5kieR6+cxiX7KllHO6eh9/WkhuV0ya6Hst/krM2UiwB tGAZYeuAGLNFnHtdGxxAmMSoUY7MiMbVG9oNwR6qe6yt7bvlfs1n+A==
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 35909F9A7; Sun, 17 Nov 2019 05:41:38 -0500 (EST)
Received: by (Postfix, from userid 1000) id 2B3CB20615; Sun, 17 Nov 2019 00:27:15 +0200 (EET)
From: Daniel Kahn Gillmor <>
To: Antoine =?utf-8?Q?Beaupr=C3=A9?= <>,
In-Reply-To: <>
References: <> <> <> <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Sun, 17 Nov 2019 01:27:14 +0300
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] review of the SOP draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Nov 2019 10:41:42 -0000

On Thu 2019-11-14 14:52:20 -0500, Antoine Beaupré wrote:
> [ dkg wrote: ]
>> I think you're proposing that if the `--sessionkey-out` file already
>> exists in the filesystem, that should be an error in the first place.
>> I'd be happy to entertain that idea, if anyone wants to provide text for
>> it.
> Yes, i think that might be preferable.

i think you're right.  thanks for that.  I've committed that change in

>> If you decide to try to write it up, please think about how it works for
>> the other scenarios where `sop` can produce output on more than stdout.
>> it would be nice if these mechanisms all had the same behavior.
> Okay, I'll keep that in mind.

On inspection, only `sop decrypt` has multiple outputs, so it wasn't as
wide a change as i'd feared.

> This is something I came up with recently while writing another
> program. I started by writing something that would read parameters from
> a config file, then realized I could also *save* parameters to that same
> file (or another). So I have two parameters, usually pointing at the
> same file (but not necessarily).
> The way "conflicts" are handled is simple: the file is first read, and
> closed. Then it is written to. As long as that's done in order and
> there's no parallelism, it works correctly.
> I was wondering if we might want to do such a suggestion specifically
> for the session key because it's this one case where you have a state
> that can be read and written. Sure, everything in sop read and writes to
> stuff, but in general they are different objects (cleartext vs
> encrypted) that won't be written to the same file unless the user does a
> mistake.

This is bizarre stuff, and i'm struggling to imagine any use case for it
with `sop` as it is currently defined, just for supplying both
--with-session-key and --session-key-out at the same time (let alone
pointing them both at the same fle).

If a user invokes `sop decrypt` with a known session key, presumably it
is because they already know the session key.  Why, in that
circumstance, would they ask `sop decrypt` for the session key?

Are you imagining a situation where the user of `sop decrypt` is
*guessing* at the session-key, but is unsure?  For example, supplying
multiple --with-session-key arguments, or --with-session-key alongside a
KEY or a --with-password argument?

I guess i can see it for some situation where "i've got a pile of
session keys and a pile of messages, and i want to figure out which
session key belongs to which message".

Anyway, I've just added an explicit failure mode when an indirect input
is pointed to a file that does not exist (in
c7c05598a5532c203de28b0dc6e1bfb69eecf549).  And given that it's now an
error to point --with-session-key at an existing file, it should be
impossible to point both options to the same file.  so hopefully this
concerns is now moot.