Dealing with multiple devices

[robinkrahl]

As we now are able to detect multiple devices and select one of them to connect to, we should decide how to deal with multiple devices.

We already have the --model option and I think we should also have a --serial-number option, maybe even a --usb-path option, to select the Nitrokey device to connect to.

But what should we do if there are multiple devices but the user did not select one of them (or the user selected a model and there are multiple devices of that model)? Currently we just use the first one returned by hidapi. This is the easiest solution, but it is also potentially dangerous. My suggestion is to abort if we have more than one eligible device, asking the user to select one of them. What do you think?

[d-e-s-o]

We already have the --model option and I think we should also have a --serial-number option, maybe even a --usb-path option, to select the Nitrokey device to connect to.

Agreed. They all seems useful and are orthogonal to each other.

But what should we do if there are multiple devices but the user did not select one of them (or the user selected a model and there are multiple devices of that model)? Currently we just use the first one returned by hidapi. This is the easiest solution, but it is also potentially dangerous. My suggestion is to abort if we have more than one eligible device, asking the user to select one of them. What do you think?

Hm. It's a tough one. I haven't looked at the changes to the API surface in detail (especially in libnitrokey), but it seems that this would imply having a new "list" call before connecting, correct? I am not a huge fan of doing so, mostly because it's an extra call (that's not a strong argument, but I'd say it is in line with how we kept things so far: close to the libnitrokey APIs, low overhead, and under the user's control; most recently with the --no-connect option to the list command, for example).

I'd also want to avoid context sensitive behavior where things work fine if nothing is specified but only a single device is plugged in, and then suddenly the program errors out if another stick is present. Such behavior tends to lead to unexpected issues at some point. But I guess one could argue that we already have that (you expect the status command to show information about the plugged in Pro stick but once you plugin in a Storage device that shows up by default, for example). To completely avoid such cases (I guess), we would require one of {--model, --usb-path, --serial-number} unconditionally. But that is swinging the pendulum too far away from the easy-to-use side, if you ask me.

My gut says that the vast majority of users wouldn't care one way or another, because they only have a single device (perhaps should be add telemetry reporting to get confirmation? :P). As such, I am tempted to say "let's just keep the existing behavior". But honestly, if you feel strongly about checking present devices upfront I am not opposed.

[robinkrahl]

I haven't looked at the changes to the API surface in detail (especially in libnitrokey), but it seems that this would imply having a new "list" call before connecting, correct?

It would call nitrokey::list_devices, which calls NK_list_devices, which calls hid_enumerate, which calls udev_enumerate_*, which reads the device information from the sys filesystem. So yes, it would imply having a new function call to libnitrokey, but it would not imply executing anything on the Nitrokey, just reading the device information from the filesystem.

I'd also want to avoid context sensitive behavior where things work fine if nothing is specified but only a single device is plugged in, and then suddenly the program errors out if another stick is present. Such behavior tends to lead to unexpected issues at some point. But I guess one could argue that we already have that (you expect the status command to show information about the plugged in Pro stick but once you plugin in a Storage device that shows up by default, for example).

Yes, that’s my point. And judging from the principle of least surprise, I think it makes more sense to do nothing if we don’t know which device the user wants to use than arbitrarily selecting one of them. If we want to enforce consistent behavior, we should execute the commands on all connected devices – but that just does not make sense for most of the commands.

To completely avoid such cases (I guess), we would require one of {--model, --usb-path, --serial-number} unconditionally. But that is swinging the pendulum too far away from the easy-to-use side, if you ask me.

Absolutely.

My gut says that the vast majority of users wouldn't care one way or another, because they only have a single device

I agree.

But honestly, if you feel strongly about checking present devices upfront I am not opposed.

It’s not that important to me either, it just feels problematic that executing a command on the wrong device could easily brick it, while asking the user to select a device won’t hurt them (and is very unlikely to bother them in the first place).

[d-e-s-o]

Can we close this issue, @robinkrahl, or is there anything left to discuss here?