Closed szszszsz closed 1 year ago
@robin-nitrokey Can you take a look at the Discussion
chapter as well?
I think it would be more intuitive if there were separate commands for adding an OTP and adding a static password. Otherwise it is hard to figure out which arguments are valid or required in which case. What do you think?
Makes sense. The whole Credential could be made in 2 steps, with 2 appropriate register calls, where the second would update the existing one instead of overwriting it.
Do you have names propositions? I understand we would leave register
to keep the user API changes count down.
Do you have names propositions? I understand we would leave
register
to keep the user API changes count down.
Maybe add-otp
and add-password
? register
could act as an alias for add-otp
for compatibility and print a deprecation warning. In that case I’d also use get-otp
and get-password
with get
being an alias for get-otp
.
how to present passwords to user (could be improved in the next PR)
The current approach looks good to me, but I think there should be additional options:
is proper user-informing message needed for the users with the older firmware / secrets app version
Yes, I think that would be good. It should be pretty easy to check the firmware version and cache it on device level. We should probably have this as a default for all functionality we add.
Sounds good! I do not see that as a blocking for merging. I think it would be worth to work on the propositions in separate tickets:
Sure, it can wait. I do not have any particular need to push it out in the first coming release.
@robin-nitrokey I presume this could be merged now, right?
This PR adds support for the new Password Safe feature of Secrets App
Changes
--secret
(was positional)get-password
- get the PWS fields from the CredentialDiscussion
To discuss:
Checklist
Make sure to run
make check
andmake fix
before creating a PR, otherwise the CI will fail.Test Environment and Execution
Relevant Output Example
Connected: