Re: [openpgp] review of the SOP draft

Clint Adams <> Sat, 16 November 2019 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A45412008C for <>; Sat, 16 Nov 2019 09:08:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hcBcaie8ybHa for <>; Sat, 16 Nov 2019 09:08:55 -0800 (PST)
Received: from ( [IPv6:2600:3c00:e000:227::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F70912001A for <>; Sat, 16 Nov 2019 09:08:55 -0800 (PST)
Received: by (Postfix, from userid 1000) id ECD8541476; Sat, 16 Nov 2019 17:08:53 +0000 (UTC)
Date: Sat, 16 Nov 2019 17:08:53 +0000
From: Clint Adams <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
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: Sat, 16 Nov 2019 17:08:57 -0000

> >> armor: armor: Add ASCII Armor
> >> -----------------------------
> >
> > [...]
> >
> >> If the incoming data is already armored, and the `--allow-nested` flag
> >> is not specified, the data MUST be output with no modifications.
> >> Data is considered ASCII armored iff the first 14 bytes are exactly
> >> `-----BEGIN PGP`. This operation is thus idempotent by default.
> >  
> > Explain why we want idempotent and why we want to do this guessing game.
> I'm at a bit of a loss here, because these seem obvious to me.
> We want a guessing game because users who don't know what they want are
> going to guess anyway, and they're likely to guess wrong.  We might as
> well guess on their behalf if they don't know.
> We want idempotent because "ensure this thing is armored" is a
> reasonable semantic request -- indeed, it's probably the *only*
> reasonable semantic request.  Perhaps we could drop --allow-nested?

As an implementer, I don't want this because this kind of run-time
detection is annoying, though it would be more annoying if the check
weren't explicit.

As a user, I don't want this because it violates the POLA.  Why would
I be directing something to "ensure this thing is armored"?  If I piped
something to base64 and it came out unchanged I would be shocked and

Along those lines, having some subcommands default to binary output
and others default to ASCII Armor also seems confusing except in cases
like `armor` and `dearmor` where the intent would seem obvious
(modulo this whole idempotency thing).