Comments (3)
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).
from nitrocli.
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.
from nitrocli.
Can we close this issue, @robinkrahl, or is there anything left to discuss here?
from nitrocli.
Related Issues (20)
- Compare strings instead of byte slices in tests HOT 2
- Access PWS slots by name HOT 8
- Improve otp subcommand HOT 1
- Validate PWS and OTP string length HOT 5
- Document scdaemon reset workaround in readme
- Publishing nitrocli-ext HOT 5
- Publishing the core extensions HOT 10
- Improve installation instructions HOT 6
- Split up commands module HOT 1
- Show retry count (< 3) in pinentry HOT 1
- "Wrong password, please reenter" after device reconnection HOT 22
- "Unexpected response: OK" if empty password is entred via pinentry HOT 1
- Add log messages to nitrocli HOT 12
- Add option to otp-cache to create custom aliases HOT 4
- pinentry-tty does not work HOT 13
- Change tests to not create python scripts during builds HOT 2
- Migrate to clap 3.0.0 HOT 2
- Move CI checks to Makefile HOT 4
- nitrocli (for NK2 Pro) not responsive while NK3 plugged in HOT 4
- Document extensions in readme HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nitrocli.