Closed dcousens closed 2 months ago
The issue is that passphrase
implies that you write a longer passphrase. The point of using "PIN" to tell people that with DA procetion you can have a 4 digit numerical pin as protection for the key. Writing "TPM Passphrase" does not convey this.
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 mark this as draft for now, unless you only wanted me to drop ce6edea?
I'll need to think a bit. Internally in the codebase I think it's better to use userauth
instead of pin
or pass
to better convey what it actually is in the context of the TPM.
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 README.md
change and I'll ponder on a better sentence. The prompt changes from "pin" to "passphrase" to keep it consistent with openssh is fine.
Does all of that sounds fine?
@Foxboron I think I have made the changes requested, should be good for review
As part of https://github.com/Foxboron/ssh-tpm-agent/commit/f8a5360393a33c7b162cb323ad09ced5a9d0738f, 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.