CLI cache is either not working or not significantly reducing time to return a secret

Hi,

I have been testing the 1password CLI (along with secrets automation, ssh and other things) for personal things but also with the idea of increasing use at $dayjob and everything is working great except for the CLI when used in interactive scenarios (like Kubernetes ExecCredential and aws credential_process) where the secret needs to be returned regularly and quickly. Obviously if your session has timed out or the desktop app requires unlocking the first access will be slow while you authenticate but the cache should provide fast access to the secret after the first time.

I will quickly outline my setup (identical experience on multiple machines):

• Manjaro Linux
• 1password desktop app 8.9.4 (system package)
• 1password cli 2.7.0 (system package)
• pam_u2f to use Yubikey to authorise polkit prompts
• I am based in Australia so I suspect latency may be an issue here with the main 1password endpoints resolving to AWS in Virginia (us-east-1). See below how I came to that conclusion.

My investigation started after I started testing this https://github.com/gunzy83/dotfiles/blob/2464e5c8017e3a88e9d8e5557ea5208aeecf719c/dot_bin/executable_k3s_op2execcredential that I use in the context of a Kubeconfig file to get the mTLS certificate and key for a k3s cluster. This was fine in Lens (it spawns a kubectl proxy which caches the credential until expiry) but when using the kubectl CLI it makes a request every time and it was a noticeable delay on each request (tab completions are particularly horrible). After testing I discovered that the requests to the 1password CLI (op read) were cumulative and I refactored the https://github.com/gunzy83/dotfiles/blob/master/dot_bin/executable_k3s_op2execcredential to use only an op item get and then use jq to retrieve the values I needed and create the json blob to be returned. General observation from this, a single secret get command will take between 1.3 and 1.5 seconds to complete.

I started testing this with some canned commands and the time builtin to zsh. I also set export OP_DEBUG=true to run the following:


time op read --cache --account my.1password.com op://Private/e2hylxuji3mpog34p5ngf47uvi/public_key


After a few tests and seeing a noticeable pause in the debug output, I also fired up wireshark and screen recording to see if I could see the client making requests to 1password's servers and see if anything correlates. The following are screenshots from the video and hopefully this will be helpful in working out timings and looking at places that things can be optimised:

First, instant output from the op CLI:

TCP connection open to one of the 1password service IP addresses:

TLS handshake:

The next set of requests/responses appeared seemingly all at once with the log output on the right. At this point the requests to 1password service have taken at least 884m even though the log messages appear to indicate it has found cache hits all round:

Secret returned in 1.426 seconds:

After this there are connections closed in wireshark.

Additional observations:

• I have also tried this with multiple requests for the same secret and it seems to wait for a response from the 1password servers each time before returning the secret.
• I just tested pulling username values from items that would definitely not be in the cache and it was consistently taking around 300ms longer (which correlates with another round trip to us-east-1 from my location in Australia).
• I also noticed that the CLI does not work when you are offline unlike the desktop app. Is this by design?

Overall I think that even if the cache is being used there is a synchronous set of requests to the 1password service that the process will wait for before returning. Can this be looked into please? Please let me know if you require any more details.

Cheers,

Ross Williams.

1Password Version: 8.9.4
Extension Version: Not Provided
OS Version: Manjaro Linux
Browser:_ Chrome/Wavebox (Chromium Based)