Only one identity sent to plugin in "identity-v1" phase when multiple are provided

[olastor]

Environment

• OS: Linux
• rage version: 0.9.2

What were you trying to do

Decrypting a file with a custom plugin and multiple identities. The two identities were in a file "ids.txt" (one per line) as such:

AGE-PLUGIN-MY-PLUGIN<identity 1 data>
AGE-PLUGIN-MY-PLUGIN<identity 2 data>

During encryption via cat secret.txt | rage -e -i ids.txt -o secret.txt.enc both identities were correctly sent from the controller to the plugin:

-> add-identity AGE-PLUGIN-MY-PLUGIN<identity 1 data>

-> add-identity AGE-PLUGIN-MY-PLUGIN<identity 2 data>

[...]

What happened

When decrypting using the same identity file via cat secret.txt.enc | rage -d -i ids.txt the controller only sends the first identity from the file:

-> add-identity AGE-PLUGIN-MY-PLUGIN<identity 1 data>

-> recipient-stanza 0 my-plugin ...

[more stanzas and grease]

-> done

The second identity was not sent. If I understand the spec correctly, the plugin should get all identities in phase 1 of "identity-v1".

[str4d]

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 (Encrypted age identities #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.

[olastor]

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

[str4d]

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.