Re: [openpgp] review of the SOP draft

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

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

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

         --dkg