Command line tool v1.8.0

felix_1p

This release contains an exciting new feature: client side caching (on Linux, BSD, macOS). The idea was to make repeated requests for the same item or vault faster.

This is how it works in a nutshell:

The cache is actually a background process, which op commands can connect to via a UNIX socket. The background process stores encrypted versions of keyset, vault and item data in memory. It doesn't have the ability to decrypt the data. op commands getting data from the cache verify that the data is up-to-date, otherwise they fetch it from the server. The background process will terminate itself if it wasn't contacted by an op process for 24 hours.
Caching is opt-in at the moment. Even though the background process will always run (it does more than just storing things in memory), op commands won't connect to it if the --cache flag isn't set.

For various reasons, in order to benefit from the cache for fetching items, op --cache list items --vault .... needs to be run prior to fetching the items (repeatedly).

Please let us know if you have any questions or run into problems.

Release notes: https://app-updates.agilebits.com/product_history/CLI#v1080001

forty2

Are there any plans to bring the caching feature to Windows? Fetching items, even by uuid and including vault, is frustratingly slow (1+s each). Having a CLI is great for integrating with 3rd-party tools (in my case, a configuration file manager) and is actually the reason I switched to 1Password (the one I used to use didn't have a Windows CLI at all). But it's so slow that I eventually had to come up with a homegrown solution using scripts to cache secrets in a local KeePass database. It's obviously much faster since there's no network involved, but it's not great to have to manually update when secrets are added or changed. It would be great if op.exe could be made fast enough that I can go straight to the source.

rickfillion

Hi @forty2,

The way that the caching mechanism currently works is quite UNIX-dependent in that it uses UNIX-native interprocess communication methods in order to cache data in a process that stays resident in memory. The general principles themselves aren't dependent on UNIX, just the actual implementation. Sadly the libraries to do this stuff on Windows with Go aren't as mature, so for the time being if we'd want this on Windows we'd have to implement a lot ourselves. None of us working on the CLI are Windows developers, so it's unlikely that we undertake that project.

That being said we still want to bring more speed improvements to the CLI that would benefit all users. There's still a lot of work for us to do in that respect.

Rick

corydodt

FYI, the official instructions for installing the CLI don't let you validate with gpg correctly.

Instructions say to import a GPG key:

gpg --receive-keys 3FEF9748469ADBE15DA7CA80AC2D62742012EA22

However, if you do that, the key is not actually imported:

gpg: key AC2D62742012EA22: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

If you try to verify the .sig later, it just says op doesn't exist.

Can you try to correct the key in the global keyservers so it does have a user id? Thanks!

SvenS1P

Hi @corydodt, thanks for bringing this up!

There are many PGP keyservers out there, and each operating system picks its own default to use. Our PGP key does have a user ID, but some keyservers choose not to publish them by default for privacy reasons. The privacy argument doesn't really apply to our own PGP key (since the email address is just codesign@1password.com), but people upload personal PGP keys containing personal email addresses in a user ID too.

If you're still having trouble, you can tell GnuPG to use a different keyserver that retains and sends the user ID by default. For example, using the Ubuntu keyserver:

$ gpg --keyserver hkps://keyserver.ubuntu.com --receive-keys 3FEF9748469ADBE15DA7CA80AC2D62742012EA22

Let me know how you get on with that! :smile:

corydodt

Hey that did work, thank you!

ag_ana

On behalf of Matthew_1P, you are welcome @corydodt :)