Re: [openpgp] review of the SOP draft

[Daniel Kahn Gillmor <[e-mail]>]

Hi Clint--

Thanks for your feedback!

On Sat 2019-11-16 17:08:53 +0000, Clint Adams wrote:
> 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.

I understand that you'd like to implement something more minimal, but
sop is trying to supply plausible interfaces for use cases for a
developer who doesn't know all the grubby details of OpenPGP but still
wants to work with confidential data as framed by OpenPGP.

> 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
> horrified.

The only use case i'm currently imagining for using `sop armor` is that
the user has come across some OpenPGP content in some environment, and
they want to transmit it over a channel that is not 8-bit clean (or
perhaps they want to put it into a text-based revision control system
that would rather not host binary blobs).

They have two choices:

 - detect whether it is already armored, and if not, invoke `sop armor`
 - unconditionally invoke `sop armor`, to ensure that it is armored.

The latter sounds simpler and easier, and it really isn't surprising or
astonishing, so i'm not sure it really violates POLA.

Vincent Breitmoser proposed the idempotency requirement over in
https://gitlab.com/dkg/openpgp-stateless-cli/merge_requests/3 and i
merged it because it seemed plausible to me.

I'm currenly thinking of dropping --allow-nested entirely, but i see
you've given that a thumbs-down on
https://gitlab.com/dkg/openpgp-stateless-cli/issues/15

if you want me to consider that more, a clearer use for nested armoring
would be welcome.

Do you have another use case that we should consider?

> 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).

I believe all the subcommands default to armored output (with the
exception of "sop dearmor").  Are you seeing somewhere where that's not
the case?

    --dkg