Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Anonymous
4 years agoAvoiding repeated biometric auths in editor subshells
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 wi...
Anonymous
4 years agoThank 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 https://man7.org/linux/man-pages/man7/credentials.7.html 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.