1password is way to verbose compared to op

[PiotrCzapla]

Is your feature request related to a problem? Please describe.

Hi Guys I'm trying to use 1password integration and I'm getting very verbose incatations something like:

{{ (onepasswordDetailsFields "qhttpfmbk5vtbfhqtt4oksjyeq").fkegrpik3ol3fta7n7sxsclbsa.value }}

Which tells me (in a year) nothing :). While I can get the same data using:

{{output "op" "read" "op://_scripts/api_pass.gpgkey/gpgkey"}}

I don't see reasons not to use the op command so I will be migrating to this. But I think it would make sense to update the documentation to recommend use of op directly as the onepasswordDetailsFileds plus two meaning less hashes is quite off putting.

It could be done by adding a note to 'Custom' section of the docs and showing how to use 'op' with the url schema Some thing like this: {{secret "read" "op://_scripts/api_pass.gpgkey/gpgkey"}}

I've just learned that secret could be used like this while creating this issue.

[marcus-crane]

I like the fact that both exist. I would prefer to use the op:// style URLs for personal secrets.

That said, as someone who uses Chezmoi to load in work secrets too, having useless (to the outside world) GUIDs is much more preferable than say op://Top Secret Plans/Unannounced Vendor/API Key as the actual path itself may leak metadata so having the ability to choose is very nice 🙂

[PiotrCzapla]

Make sense, but what about the places where you assign the variable to? I've checked your dot files (hope you don't mind), and it seems that it is the case in every time. Have a look:

Your GitHub token?

export GITHUB_TOKEN={{ (onepasswordDetailsFields "gupafjpzbp67i4evkrzv5quos4" "wiikjuo2a5lhi6gpaesnmjvcmy" "my").password.value }}

Your data dog api:

export TF_VAR_datadog_api_key={{ (onepasswordDetailsFields "62n7qafj3crbjqtunwktgzoguq" "3rs5ui53xhp5zfe63vltdpb6o4" "vendhq").username.value }}

And your password to slack to control away messages:

   - name: 'devdeck_slack.slack_deck.SlackDeck'
      key: 2
      settings:
        api_key: '{{ (onepasswordDetailsFields "sf5xjz3rdsvp6c2gt4emwykqmq" "wiikjuo2a5lhi6gpaesnmjvcmy" "my").password.value }}'

But I see the point, there are some advantages in using ids like:

• the url won't break if your team mate decide to change name of the item
• it may help prevent leakage if you decide to share the whole chunk of a file in 1password (I do so for part of .ssh/config)

I've added this enhancement mostly to improve docs as I was beleving that I have to type: onepasswordDetailsFields "gupafjpzbp67i4evkrzv5quos4" "wiikjuo2a5lhi6gpaesnmjvcmy" "my").password.value

instead of: op://_myscripts/github/password

It is a bit off putting for new comers. At least for me, this delayed the move from homeshick by few months. (it took me 3 attempts of reading the docs to decide to give chezmoi a chance.) .

[marcus-crane]

Oh, just to be clear, I only learnt that the op:// format existed just the other day so I haven't used it anywhere in my own dotfiles but I might move over to it for my less "secret" tokens 😉

I agree that it's definitely more user friendly and probably would be a reasonable default with the option to use the more advanced GUID path when you need the extra obfuscation.

The only catch with the op:// syntax is that if you use multiple 1Password accounts (not vaults but actual accounts), you'll need to use the --account flag or else chezmoi may not access the correct account.

I think something like this should do it: {{output "op" "read" "op://Personal/Github/Username", "--account", "my"}}

$ op read op://Personal/Github/Username
[ERROR] 2022/07/24 11:50:06 could not read secret op://Personal/Github/Username: could not get item Personal/Github: "Personal" isn't a vault in this account. Specify the vault with its UUID or name.
$ op read op://Personal/Github/Username --account my
marcus-crane

[twpayne]

Thank you all for this discussion. I wasn't aware of the op read command when I added the 1Password template functions.

I propose to add a onepasswordRead template function that takes a variable number of string arguments and passes them all to op read and returns the output, so you can write things like:

{{ onepasswordRead "op://Personal/Github/Username" }}

or

{{ onepasswordRead "op://Personal/Github/Username" "--account" "my" }}

How does this sound? What improvements would you suggest?

[twpayne]

cc @halostatue as a 1Password/chezmoi user, in case you have input :)

[halostatue]

I think that onepasswordRead would work nicely, although I think that passing --account isn’t necessary.

{{ onepasswordRead "<op-url>" ["<account-id>"] }}

I would also suggest that we consider shortening the commands here:

{{ opRead "<op-url>" ["<account-id>"] }}

[PiotrCzapla]

I would focus on the docs as the opcli should be used directly so that that one put op://urls in to env variables and then run op run command. Some thing like this:

Like this

export AWS_ACCESS_KEY_ID=op://dev/aws/key_id
export AWS_SECRET_ACCESS_KEY=op://dev/aws/accces_key
export AWS_DEFAULT_REGION=op://dev/aws/region

alias aws=op run aws

Will make the aws command know the secrets instantly when executed.

I use 1password in chezmoi mostly to remove the bits of my config that should not be visible on public github profile like IPs of my hosts in the .ssh/config. Or for things that do not accept environment variables.

I prefer shorter names so {{opRead “op://url”}} sounds lovely. but I’m also happy with {{output “op” “read” … }} or {{onepasswordRead ..}} the most important bit is to update the docs so other ppl that are using one password won’t think that there is only the hard way of using chezmoi.

Btw the more I use this tool the more I love it :) thank you for building this !

On 26 Jul 2022, at 21:42, Austin Ziegler @.***> wrote:

 I think that onepasswordRead would work nicely, although I think that passing --account isn’t necessary.

{{ onepasswordRead "" [""] }} I would also suggest that we consider shortening the commands here:

{{ opRead "" [""] }} — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.