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
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp