Only one identity sent to plugin in "identity-v1" phase when multiple are provided about rage HOT 3 CLOSED

One related question: Does the same apply to recipients, as well?

It generally shouldn't, because there's an asymmetry here. Decryption stops at the first identity that succeeds, so order is relevant. Encryption necessarily uses all provided recipients and identities, so the order doesn't change which plugins get called.

from rage.

tl;dr This is a UX consideration specifically for the CLI; if you want to leverage merging, you will need to use the age crate directly.

When I wrote the original draft of the age-plugin spec, my intention was for each identity plugin to only be called once (the fewest possible subcommand invocations). Hence the v1 identity plugin supports multiple identities being provided in phase 1. The age crate also implements this: age::plugin::IdentityPluginV1::new takes &[age::plugin::Identity].

Initially, this is also what I implemented in rage: the -i flags would be grouped by plugin, and then IIRC the native identities would be tried first, followed by the plugin identities in a non-deterministic order. It was this that @FiloSottile raised as a UX problem: CLI users had no way of guessing or influencing what order identities were tried. This was a problem because plugins can have unbounded complexity, and users can reasonably want to have rage try more complex identities later.

As documented in #236, after a long UX discussion we decided to make -i flags deterministic:

• Identity files are tried against a ciphertext in left-to-right order from the CLI flags.
• Identities within an identity file are tried in top-to-bottom order.
• Encrypted age files (#235) have their identities tried in-place (as if the unencrypted identity file had been passed instead).
• No identities will be coalesced for plugins.
  • This means that plugin binaries will be invoked by rage once per identity, and will only ever see one add-identity command. The plugin protocol still supports more complex use cases.

from rage.

@str4d Thanks for these clarifications! I think it'd be good to describe or reference this cli-specific behaviour in the spec, so that plugin developers don't invest too much time into optimizing the order of trying identities if their target users are cli-only.

One related question: Does the same apply to recipients, as well? I think the cli behaviour of rage and age are diverging when multiple plugin recipients are passed (that's why I also created FiloSottile/age#526). I think rage passes all recipients at once to the plugin when specifying multiply via -r age...rec1 -r age...rec2, while age makes individual plugin calls per recipient.

from rage.