-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFD 198 - Hardware Key Pin Caching #51537
Conversation
91816a7
to
40ae12a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd consider combining this with RFD 199 - I don't know that there's enough here to merit a separate RFD, and you can't "implement" this RFD without also implementing 199.
You may be right, but my thought process here is actually that the changes described here are self contained - I already have the single PR prepared for it. The "multi-process solution" involving Teleport Key Agent doesn't actually require any additional changes to the PIN caching logic, it just arises as a free benefit with the Key Agent. In other words, PIN caching has to do with changes to the client key storage, Teleport Key Agent deals with creating an API for the client key storage. Perhaps I should drop this RFD, open the PIN Caching PR with a thorough description, and handle any discussion / security concerns in the PR comments? I'd also want to get Doyensec's thoughts on the PIN caching security and whether memguard is the right choice. Then I can create a brief section in the Teleport Key Agent RFD describing the interaction without overcomplicating that RFD further. @zmb3 WDYT? |
I've moved the important details from this RFD into RFD 199 |
No description provided.