CLI is so/too slow

tuxtof

Hey folks 👋



really excited of all the new dev features in 1Password 8
ssh agents rocks and the op run cli integration is a very good idea

BUT

oc performance are a nightmare, it take almost 5 seconds to run and even with --cache it take always 2.5s
based on that i can't imagine put it in alias on my more frequently used command as it will entirely kill my workflow

i can't imagine wait 2-5s more for a command who usually is almost immediate

any improvement planned on this side ?

---

1Password Version: 8.7.0
Extension Version: 2.3.1
OS Version: macOS 12.3

Horia.Culea_1P

Hey, @tuxtof , yes, definitely!
We have had a number of complaints about this, and it is currently an issue under investigation.
We hope to roll out an optimisation soon. We'll make sure to keep you posted in this thread.

Thanks a lot for your feedback!
Best,
Horia

tuxtof

Good news thanks

Horia.Culea_1P

No worries, let us know if we can help with anything else!

tuxtof

Everything else is ok
I let you focus on op 😜

markartshely

I'm going to second this. I was very excited to use op inject for some property files that we currently have stored in an inconvenient way. However it appears that performance is linear in the number of references in the file. We have almost 400 in one file and it takes a full minute to inject. Here it doesn't seem to matter if I use --cache or not. I would really like to use this for our production secrets, but at the moment I'll hold off until injection only takes a few seconds.

Ryan Parman

Also running into this on macOS. I have 16 environment variables containing tokens on the start-up of a new shell session. Prepending each of my export VAR calls as time export VAR, I was able to get the real timing. Fetching them one-by-one takes 1–2 seconds, plus the time for my Apple Watch to tap my wrist asking for permission (≈5 seconds).

• (15 × 1) + 5 = 20 seconds (best case)
• (15 × 2) + 5 = 35 seconds (worst case)

Of course, this is unacceptable. I was able to improve the efficiency by grouping them with the same tag, and only querying the 1P backend once, and using the --cache flag:

OP_DATA="$(op item list --tags "type:env" --format=json --cache | op item get - --format=json --cache)"
export ARTIFACTORY_ACCESS_TOKEN="$(echo "$OP_DATA" | jq -Mr '. | select(.id == "{id-value}") | .fields[] | select(.id == "credential") | .value')"
export HOMEBREW_GITHUB_API_TOKEN="$(echo "$OP_DATA" | jq -Mr '. | select(.id == "{id-value}") | .fields[] | select(.id == "credential") | .value')"
export GITHUB_TOKEN="$(echo "$OP_DATA" | jq -Mr '. | select(.id == "{id-value}") | .fields[] | select(.id == "credential") | .value')"
export PAGERDUTY_TOKEN="$(echo "$OP_DATA" | jq -Mr '. | select(.id == "{id-value}") | .fields[] | select(.id == "credential") | .value')"
export AC_PASSWORD="$(echo "$OP_DATA" | jq -Mr '. | select(.id == "{id-value}") | .fields[] | select(.id == "credential") | .value')"

unset OP_DATA

This saves time, but is very verbose. Sure, I can wrap it in a function, but still. Doing things this way (fetch once), each jq query takes between 0.04–0.11 seconds. Adding 5 seconds to double-click my Apple Watch for the initial request took (adding the real values from time):

6.461 seconds.

Still a little slow, but MUCH better. This also has the benefit of the environment variables being hydrated from a secure data store, rather than from plain text files on-disk. Cool, but this can still be better.

On macOS, Keychain Access.app is the primary OS-level credential storage solution. Windows and Linux have their own, but I'm going to talk about macOS for the moment. The CLI tool that allows you to interact with Keychain Access.app is called security.

$ time security find-generic-password -a testy -s api_credential -w
my_secret

real    0m0.094s
user    0m0.026s
sys 0m0.043s

Running this repeatedly, I'm seeing the same kinds of times as the jq commands above: 0.04–0.11 seconds. But the benefit is that this works for all macOS users, and is less complex to add support for in your shell session.

The best solution would be something similar-in-spirit to AWS Vault. Tokens are fetched on-demand, passed to a sub-shell where a command executes, then after it's done, the sub-shell ends taking the secret values with it. Something in the spirit of:

$ secrets exec github-personal -- curl -XPOST -H "Authorization: Bearer ${GITHUB_TOKEN}" https://github.com/...
$ secrets exec github-work -- curl -XPOST -H "Authorization: Bearer ${GITHUB_TOKEN}" https://github.enterprise.internal/...

There should probably be a config file (like ~/.aws/config) so that you can configure which environment variable should receive the value of the credential, the name of the field to fetch, etc., but it's a one-time setup sort of thing.

And it has the benefit that — for long-term, interactive shell sessions — the environment variables don't hang out in memory for very long, enabling a rogue script or a poorly-written VSCode extension to write the values of your environment variables to disk as a log file (which happened to me recently).

Horia.Culea_1P

Thank you all for your reports, and thanks, Ryan, for the proposed optimisation.
I'll make sure it all goes to the internal ticket where we track any performance improvements.
We'll keep this thread posted, as soon as we roll out any amelioration for the issues I see being reported.
I thank you all for your patience, and for using 1Password CLI.
Looking forward to hearing about any other pain-points, related or not to performance!

Best,
Horia