Forum Discussion

Former Member's avatar
Former Member
4 years ago

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 ...
cli
Former Member's avatar
Former Member
4 years ago

Hi Andi,

Thanks for the reply. I am now not sure the requests going out to the 1password server have that great an impact and may be a red herring.

I ran a test of the CLI with OP_BIOMETRIC_UNLOCK_ENABLED=false and did the manual signin. After it was signed in I ran read commands on various entries in my Private vault and found:

  • Cache hits will return in 1.2-1.3 seconds.
  • Cache misses return in ~1.5 seconds.
  • Curiously, all requests showed no activity to the 1password service in Wireshark, including the cache misses (does this mean once you are logged in there is a copy of the DB copied down?).
  • If I disconnect my network the cli complains about not being able to resolve DNS for my.1password.com as expected but curious considering the behaviour above.
  • I noticed this with biometric and without that the CLI pauses right before DEBUG | InitDefaultCache: successfully initialized cache. This seems to indicate that most of the slowness is coming from re-initialisation of the cache (or something else coupled to that step) and my apparent correlation of the requests to this event may have been a red herring. Hopefully that might give a good starting point for debugging.

Note: my.1password.com has the same list of IP addresses when I perform a DNS lookup from the other day so I did not have to shange my wireshark filter.

Another curious observation is that there are no requests made to the 1password servers when biometric unlock is waiting on me to respond, it only reaches out after I have clicked allow and then unlocked with my Yubikey via polkit.

I will leave this with you as I think there is little more I can do on my end other than explore other caching options in between the op cli and kubectl/aws cli. Even at 1.2 seconds the CLI IMO is still too slow for interactive use-cases (particularly when tab-completions are in use) and it should not be this slow if using the local cache. As a comparison, aws eks get-token returns in ~300ms and it reaching out to a web service 1000km away from me.

Thanks,

Ross Williams