nitropy nk3 update fails with "Critical error: unhandled exception: SPSDKConnectionError() (due to missing permissions)

[wlatendresse]

The following command sequence fails with an error and seems to leave an attached NitroKey 3 in an unusable (bootloader) mode:

• OS and environment: Relatively clean linux system (Linux Mint 22.3)
• Successful pynitrokey installation via 'pipx install pynitrokey'
• Firmware download via 'nitropy nk3 fetch-update --version v1.8.3 .'
• Firmware verification via 'nitropy nk3 validate-update firmware-nk3-v1.8.3.zip' (this step is of course unnecessary but was the sole reason for this situation)
• Firmware installation of successfully downloaded firmware via command 'nitropy nk3 update --version v1.8.3 firmware-nk3-v1.8.3.zip'

Output for the last command:

nitropy nk3 update --version v1.8.3 firmware-nk3-v1.8.3.zip 
Command line tool to interact with Nitrokey devices 0.12.3
Current firmware version:  v1.8.1
Updated firmware version:  v1.8.3

Please do not remove the device or insert any other Nitrokey devices during the update. Doing so may damage the device.
Do you want to perform the firmware update now? [y/N]: y

Please press the touch button to reboot the device into bootloader mode ...

Critical error:
An unhandled exception occurred
	Exception encountered: SPSDKConnectionError()

--------------------------------------------------------------------------------
Critical error occurred, exiting now
Unexpected? Is this a bug? Would you like to get support/help?
- You can report issues at: https://support.nitrokey.com/
- Writing an e-mail to support@nitrokey.com is also possible
- Please attach the log: <---SNIP---> with any support/help request!
- Please check if you have udev rules installed: https://docs.nitrokey.com/nitrokeys/nitrokey3/firmware-update#troubleshooting-linux

Logfile:

nitropy-20260714T143229-l75mg7n4.log

The udev-rules have NOT been installed prior to the execution of the above command sequence.

The log file itself indicates that the problem appears to be an access issue with "/dev/hidraw[X]".

Although the access issue occurs even before the output shown above, the script cheerfully continues as if nothing had happened.

The necessary permissions should and MUST BE CHECKED BEFORE performing an operation!

Since the output of relevant information for a nk3 stick ('nitropy list') works without any problems, the script should probably check whether write access to the according HID devices actually exists at all before guiding the user through the remaining installation steps (which will fail anyway due to the lack of necessary write permissions) ...

Output for 'ls -al /dev/hidraw*':

crw------- 1 <----------- SNIP ----------> /dev/hidraw0
crw------- 1 <----------- SNIP ----------> /dev/hidraw1
crw------- 1 <----------- SNIP ----------> /dev/hidraw2
crw------- 1 root root 241, 4 Jul 14 14:32 /dev/hidraw4

The device remains in bootloader mode. An update is still possible when executing nitropy nk3 update --version <YourVersion> --ignore-warning update-from-bootloader your-firmware-nk3-v1.x.x.zip as root.

[wlatendresse]

For the sake of completeness:

nitropy version results in Command line tool to interact with Nitrokey devices 0.12.3

I am aware that the absence of udev rules is a problem that has also been described in Firmware Update - Troubleshooting.

Nevertheless, I believe it is sensible and necessary for the script itself to check for the presence of these rules when the program starts and, if necessary, to generate a warning if the rules are missing.

Since the VendorIDs and ProductIDs are unique, it is easy to verify whether the corresponding rules exist on an OS and, if necessary, terminate the process with an appropriate error.

[wlatendresse]

Perhaps someone could answer the following question:

nitropy can execute most subcommands even without any udev rules installed (which, in principle, only ensure that write access to the corresponding /dev/hidrawX device is available).

Which of the commands registered in cli.__init__ require write access, and which require only read access to the device?

With this information, nitropy could likely be expanded relatively easily to make it more user-friendly.

[wlatendresse]

After realizing that "click" is used extensively for the command line - and that, unfortunately, it doesn't seem to know any preconditions that determine whether a command can be executed at all - two questions arise:

1. Is "click" even the right package for this purpose? (In my opinion, it isn't.)
2. Is it still possible to implement a command “invisible” to the user as a precondition before a command is executed, one that would still ensure exactly that?

To put it simply, in case of running on Linux, the program could run a grep (in terms of functionality, not necessarily this exact executable) on existing udev rules and check for the presence of the combination of idVendor and idProduct as a prerequisite.