Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Solved
1Password CLI vulnerability?
I saw this vulnerability disclosure on hackernews and the basic gist of it seems to be that if you have malicious software running on your computer and you give the credentials to your 1password acco...
This thread was discussed further in the 1Password Developer Slack, but also wanted to share the response here for visibility:
These are great points you're making, and more fine scoped local access has been on our radar for a while. Some background: on the CLI side, we started out with an authorization model that would enable every use case right off the bat. Managing vaults, creating service accounts, provisioning users, etc. The drawback of that approach is that if you just want to load a few secrets for local development, you'd authorize more than needed. Now, because of its power, we've made it so that you're only authorizing the current shell / parent process with a timeout of 10 minutes of inactivity. This adds a layer of protection in the malicious IDE extension case, for example.
For the "read secrets for local dev" use case specifically, we recently announced a built-in .env integration, which does scope local read access down to only a specific set of pre-defined secrets. Besides addressing the access scope point, it'll also give you offline support and a new UI to manage and collaborate on secrets in a given environment.
That said, we do certainly still see value in bringing more fine-grained local authorization to the CLI / SDK side in the future.
1P_Vithyea
1Password Team
1Password TeamThis thread was discussed further in the 1Password Developer Slack, but also wanted to share the response here for visibility:
These are great points you're making, and more fine scoped local access has been on our radar for a while. Some background: on the CLI side, we started out with an authorization model that would enable every use case right off the bat. Managing vaults, creating service accounts, provisioning users, etc. The drawback of that approach is that if you just want to load a few secrets for local development, you'd authorize more than needed. Now, because of its power, we've made it so that you're only authorizing the current shell / parent process with a timeout of 10 minutes of inactivity. This adds a layer of protection in the malicious IDE extension case, for example.
For the "read secrets for local dev" use case specifically, we recently announced a built-in .env integration, which does scope local read access down to only a specific set of pre-defined secrets. Besides addressing the access scope point, it'll also give you offline support and a new UI to manage and collaborate on secrets in a given environment.
That said, we do certainly still see value in bringing more fine-grained local authorization to the CLI / SDK side in the future.
