Problems with op v2 when integrating with chezmoi

austin

I’ve recently upgraded to op v2, and it’s breaking chezmoi fairly hard. Even if the first issue is fixed (either in op or in chezmoi), there appear that there will be different errors based on whether biometric authentication is enabled or not.

Issues

1. op signin protocol has changed for the worse. Previously, one could use op signin <account>. Now, it is necessary to use op signin --account <account>. This is a needless breaking change. It’s easy enough to work around with a version check. This is preventing the use of chezmoi on my machine at all because it cannot continue (I’m going to be submitting a patch; I’m annoyed that I have to do so).
2. Without biometric authentication: op signin emits a different OP_SESSION_* variable than it used to. The session variable used to be the account alias OP_SESSION_<account>. Now it's OP_SESSION_<UUID>, which means that anything that looked for OP_SESSION_<account> will not find it, and because it cannot find the UUID, it will either prompt for login again or it will fail. Again, I feel like this is a needless breaking change. In the context of chezmoi, it means that I cannot op signin before running chezmoi and will be asked for my password again.
3. With biometric authentication: no OP_SESSION_* variables are set. On the other hand, the biometric authentication just works.

---

1Password Version: 2.0.0
Extension Version: Not Provided
OS Version: Not Provided

austin

Chezmoi has merged a patch that handles issue 1, although it has not yet been released (the likely version is 2.15.0).

Issue 2 is still going to be a problem, although the documentation will be updated to point out this issue. This may be able to be resolved in code if we can figure out how to use op account list --format=json to map the accounts properly. The loss of the OP_SESSION_<shorthand> is fairly significant, though. It’d be nice if it could come back.

austin

I’ve started a discussion on a way that chezmoi could address issue 2. There are some questions that I have raised on that discussion which could use some input from Agilebits. https://github.com/twpayne/chezmoi/discussions/1974

austin

Please note that there is a difference in output for op account list --format=json depending on whether biometric authentication is enabled. IMO, this is a bug.

With biometric authentication enabled, the keys for the account list are url, email, and user_uuid. With biometric authentication disabled, a new key (shorthand) is now available. The lack of shorthand makes it harder to present a uniform data solution in chezmoi.

Horia.Culea_1P

Hey @austin,

Thank you for reaching out to us. Let's address these issues in order:
1. op signin signature has changed - this has been done so by design. While all the other commands accepted the account filter through a flag, op signin was the odd one out. This change came, in our opinion, to ensure consistency and intuitivity in the CLI, between different commands.
2. session token name changed - We tried, as much as possible, not to make this a breaking change. While OP_SESSION_<account_id> is now set in the environment instead of OP_SESSION_<shorthand>, the CLI actually fetches the token from the latter envvar as well, if it cannot find the first one. Can you please elaborate a bit on your use-case here?
3. Indeed, no OP_SESSION_*. You can find more details about biometric unlock here: https://developer.1password.com/docs/cli/biometric-security#technical-design
4. Different response for op account list --format json - within biometric unlock, there is no such concept as an account shorthand. You can indeed use the first part of your sign-in address as an account filter, but that is different from an account shorthand. To state one difference, the user cannot modify that via the CLI.

I get the feeling that there may be more questions within your messages, so please, do follow up and let us know how can we help you further!

Best,
Horia

austin

Most of the questions that are "within" my messages are detailed at https://github.com/twpayne/chezmoi/discussions/1974 and are specifically related to using 1Password with chezmoi, which is a dotfile management tool that can integrate with 1Password and other tools in order to retrieve secrets and documents so that they are not stored in your dotfile repository. Input from 1Password personnel on this discussion would be of great value.

An example of how this would be used would be something like this template where I fill my AWS credentials file from a combination of a static list in my chezmoi.toml configuration file and 1Password documents:

{{- range .aws.credentials }}
{{ if eq .type "1p" -}}
{{ printf "# aws-credentials: %v (from %v %v %v)" .name .type .account .vault }}

{{ onepasswordDocument (printf "aws-credentials: %v" .name) .vault .account }}
{{- end -}}
{{- end -}}

That would turn into something like {{ onepasswordDocument "aws-credentials: personal" "Personal" "myaccount" }}, which turns into an op command that looks like op document get 'aws-credentials: personal' --vault Personal --account myaccount. If I my account is actually named foobarbaz, but I had set the shorthand myaccount, I now have to change my configuration to either use foobarbaz or the UUID…if I’m using biometric authentication. Things get much harder if I’m not, because of the change to the OP_SESSION_* variables.

Now to address your responses:

1. I disagree with your reasoning on this. op signin <account-identifier> is much the same as op document get <document-identifier>, because op signin is using the first parameter. It would be better, IMO, to make it such that op signin works without an identifier (signing into the last used account?), with an identifier (signing into the named account), or with --account identifier. That is, if I have last signed into myaccount, then op signin, op signin myaccount, and op signin --account myaccount should all be equivalent.
2. Chezmoi reads from OP_SESSION_<shorthand> and has no way to look up OP_SESSION_<account_id>, so the change from OP_SESSION_<account_id> to OP_SESSION_<shorthand> is a breaking change, because the session can no longer be retrieved by the shorthand name which has been (optionally) used in the templates. This will force everyone to change their account identifier to the UUID. (The discussion mentioned at the top is a way that we can possibly work around this.)
3. No issues with the biometric item missing OP_SESSION_*. Everything just works.
4. The missing shorthand may be a breaking change for people who had different shorthands than their account names. Its presence would be ideal, and again this is discussed in depth in the Github discussion linked above.

simon_1P

Hi @austin, I'm sorry about 1) the friction you're having upgrading to v2 and 2) our slow response. I'm engaging in the GitHub discussion now and exploring what we can do on our end to take away friction points. I already said it on the GitHub thread and I will say so again: thanks so much for the overview and detail in your communication both here and in the GitHub discussion!

simon_1P

I disagree with your reasoning on this. op signin is much the same as op document get , because op signin is using the first parameter. It would be better, IMO, to make it such that op signin works without an identifier (signing into the last used account?), with an identifier (signing into the named account), or with --account identifier. That is, if I have last signed into myaccount, then op signin, op signin myaccount, and op signin --account myaccount should all be equivalent.

I think the biggest difference with op document get <identifier> and friends is that they already specify the resource name in the parent command: "document". I think the equivalent for signin would be: op account signin <account>.

Now that you're prompted to sign-in on other commands and signin is no longer a required action to perform before any other command, it may become an option to consider moving signin and signout under op account (we'd continue to support the root-level invocations for backwards-compatibility).