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