Skip to content
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

upgrade_by_passwd.py can brick the key on single invocation #12

Open
nakato opened this issue Feb 23, 2019 · 6 comments
Open

upgrade_by_passwd.py can brick the key on single invocation #12

nakato opened this issue Feb 23, 2019 · 6 comments

Comments

@nakato
Copy link

nakato commented Feb 23, 2019

A single invocation of "upgrade_by_passwd.py" with the wrong admin key will brick the key in a single run if factory_reset=no

I would not expect the tool to try a single pin 3 times in a row without prompting, it would probably be best to make this less aggressive.

@alex-nitrokey
Copy link
Contributor

@szszszsz I think, a fix would be to delete this loop. In my opinion a user, not the script should restart if something failed.

But this may should be fixed upstream, don't you think? Shall I ask NIIBE on the gnuk-mailingslist?

@szszszsz
Copy link
Member

@nakato Agreed.

@alex-nitrokey That is a good candidate for the cause indeed. The loop should only continue in a case, where the connection issues had occurred, not when the PIN had been incorrect. It would be the safest to remove it for now.
Could you prepare a patch for NIIBE and send him via the mailing list? It would be faster to explain the problem, when the fix is presented as well, and perhaps it will be merged directly. We should apply the patch in our repository anyway, until the handling is improved.

@alex-nitrokey
Copy link
Contributor

I created a PR in #13

I added a check if auth attempt actually worked. The loop breaks if the authentication failed. This helps to keep the feature of killing scdaemon automatically intact.

@jans23
Copy link
Member

jans23 commented Feb 25, 2019 via email

@alex-nitrokey
Copy link
Contributor

Did you check if latest Gnuk contains a fix for that issue already, perhaps?

Well... actually I should have, but I didn't.

@alex-nitrokey
Copy link
Contributor

Doesn't look like it.

szszszsz added a commit that referenced this issue Apr 25, 2019
In case the wrong PIN is supplied, and the factory-reset is set to no, this would lock the device entirely.
Temporary fix for #12, while waiting for #13.

Signed-off-by: Szczepan Zalega <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants