-
Notifications
You must be signed in to change notification settings - Fork 20
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
Use passphrase terminology, not PIN #57
Conversation
The issue is that The reason why it says so in the askpass prompt is because there are askpass programs that cache the "passphrase" based off on the "askpass" prompt. Thus you end up with inconsistentcies like this. So I'm not really convinced I want all of these changes. |
That's fair, and I'm thinking about how maybe we can balance the best of both. |
I'll need to think a bit. Internally in the codebase I think it's better to use |
Okay, I've decided. Drop the change from "pin" to "pass" in the codebase as I plan on changing the references to "userauth" which is the correct word in the context of TPMs. I think we should drop the Does all of that sounds fine? |
@Foxboron I think I have made the changes requested, should be good for review |
I additionally added d45fd23, which seems to be different - I can drop that if needed |
As part of f8a5360, you used the phrasing passphrase, not PIN; and the usage seems inconsistent throughout.
This pull request replaces any usage of
pin
withpassphrase
(orpass
internally), such that the usage and terminology (and stdout output) is somewhat consistent withssh-keygen
.I think pointing out that TPM 2.0 has well defined anti-hammering protection is informative as to the type of passphrase you could use compared to hinting specifically that you have PIN support; which nearly sounds like a limitation to me than a feature.
However I am not too opinionated on keeping ce6edea in this pull request if you feel otherwise.