Avoiding repeated biometric auths in editor subshells

Options
apiology
apiology
Community Member
in CLI

Hi!

I was super happy to see the new 1Password CLI 2.x functionality with biometric unlock! It sounds super useful for developer purposes. I'm having some trouble when I try to integrate it with my workflow, though.

I would like to use 1Password-CLI 2.x to automate various tasks which I start in my editor, using the new biometric unlock feature. However, because each task creates a new window, I must authenticate each time.

This is really a drag as my Apple Watch doesn't seem to always 'catch' the bluetooth request to authenticate, leaving me no option but to cancel and restart the command.

It appears the multiple authentication requests are because the "session credentials" described here are based on TTY name and some kind of "start time": https://developer.1password.com/docs/cli/biometric-security/#session-credentials

Is it possible to override this behavior so that I use the same session for all terminal windows started by my editor?

I'm using op 2.0.0.

1Password Version: 8.7.0
Extension Version: Not Provided
OS Version: macOS 12.3.1

Comments

  • Joris_1P
    Joris_1P
    Options

    Hey!

    It's exciting to hear that you are taking the CLI and building a workflow on top of it. That is exactly what we wanted to enable!

    We are still looking into improving the authorization prompting behaviour. Could you tell me which editor you are using and which feature of that editor your are using to call the CLI? That would allow me to run some tests locally to see if there is anything we can do to make this experience a bit smoother.

    Joris

  • apiology
    apiology
    Community Member
    Options

    This is emacs, using M-x compile.

    That said, I would expect any editor that can be programmed to shell out to run tasks would use a new TTY for each run, and presumably also reset whatever 'session start time' is being described in the above document (what is that?).

  • Joris_1P
    Joris_1P
    Options

    Thank you for providing those details. I am now able to reproduce what you are describing. You are correct that emacs is using a new TTY for each compile command it runs. Since authorization for the CLI is stored for a specific TTY, authorization does not carry over between commands.

    Unless there is a way for for emacs to not use a new TTY for each compile command it executes, it will be tricky to solve this without making some impactful changes to the security model.

    I have filed an issue for myself to dig into this a bit further to see if there is something we can do without compromising on security for other use-cases.

    and presumably also reset whatever 'session start time' is being described in the above document (what is that?).

    It's the time at which the process that is the session leader (the process with a process ID that equals the session ID, see the Linux manual for more details if you're interested) originally started. We use it to uniquely identify a session. The reason why we add the start time, is that the ID of a session can be reused after all processes in a session are terminated. We do not want previously granted authorization to carry over to this new session, so we also add the start time into the mix.

    This model is based on what sudo does internally to cache its authorization.

  • apiology
    apiology
    Community Member
    Options

    Thanks for digging in! I do hope you can find a solution. I'm eager to use the new biometric auth support; I currently stash the OP_SESSION env variable in the keychain and would love to start using biometric auth instead: https://github.com/apiology/with-op

  • Joris_1P
    Joris_1P
    Options

    You're welcome. Thanks for sharing your feedback!

This discussion has been closed.