Hi,
I just try the new Nitro-App Version 0.5.1 and it looks like it has still similar strange behavior of the key:
I do have an terminal window open in the background (delivered with macOS ) when I open the Nitro-app. Currently I du the first initialization and the red LED on the NK Storage is blinking nice. The statusbar is the top most window ( whether it has the focus or not - that already is a bit strange )
But when I click now into the Terminal window, I get an immediate message from Nitro-app 0.x that the key is disconnected. When I click back on the still open window of the Nitro app, the key will be connected again ( so Nitro-app message is telling). I can repeat this any time with the terminal window. While writing this text ( in Safari Browser) the focus is on the browser, but the NK storage is still connected.
When I use IORegistryExplorer, there is no disconnection shown at any time. So it might be a wrong message from Nitro-App ?
Or a bug in the Terminal/Console as I can only generate it with that program.
Regarding status-bar - do you mean the first initialization with filling SD card with random data? Do I understand correctly the window with progress bar is disturbing you from normal use of the OS?
I have reproduced your issue on Yosemite in another scenario. The problem comes from OSX preventing applications to communicate when different levels of authorization is run at once. In your situation I guess that terminal is run on elevated privileges to increase security. When you switch to the terminal window Nitrokey App is cut off from its HID resources and they are restored when you click any user-privilege app. When you check connection through IORegistryExplorer it is not shown since it is probably also run as root (since it requests system information).
There are couple of options here:
Running Nitrokey App in elevated mode (as root/administrator or with sudo) - this works on Yosemite, that is it prevents device disconnection
Running terminal with user privileges - if bundled terminal does not have such option, possibly try to use any other application with such features
Yes. This dialog box will always stay - maybe a bit grayed out, but always in front of the other windows. So you can’t see what is behind that dialog box …
Regarding point 2. : I tried sudo … nitro-app in the terminal and as you have described, the NK stayed connected. My Terminal ( build in from macOS ) is opening under root a login and then under my account the shell - a bit strange !
[quote]Yes. This dialog box will always stay - maybe a bit grayed out, but always in front of the other windows. So you can’t see what is behind that dialog box …
[/quote]
Regarding device connection/disconnection depending on terminal focus, I have tested this issue on Sierra 10.12.1 and it does not reproduce. I could use terminal normally. OSX was upgraded. @Peacekeeper, Was your installation clean or upgrade?
I also upgraded. Nevertheless I see that I get a login under root and then my shell under my user name. I am working not as an Administrator on the system - instead I am using a normal user.
As I have upgrade to Nitro-app 1.0 and FW 0.45 on my NK Storage, here some news:
When I open the terminal, I still have the same problem - now a bit more often: connect and disconnect
My terminal runs under my non-pre user account, but there is a login process opening that terminal, that runs under root ==> so still the problem, that iTerm Window ( regardless what I do there ) leads into frequent/regular connect and disconnections
When I run sudo /Applications … /nitro-app Looks like DEBUG is always on as it dumps into my window. That would also be in line with a regular gimps blinking of the NK Storage LED in red ( You might not see that , when you have the dark plastic case around it ) I assume the app is pulling ? So any way to turn that off ?
The connection/disconnection issue is caused by unusual setup (I have not seen this issue on my daily usage tests). I am not sure this could be fixed since I guess the cause is in the OS policy regarding using applications started with different permissions level (similar mechanism is under Windows).
You can try running the App with sudo or find another way to allow it to always access the device (regardless of current user being active).
Regarding the log output in the console, this should be fixed with next release - today or tomorrow.
When you look in your activity monitor under macOS: is your Terminal started with a login process ?
Just to be clear: the problem is not that I can’t start Nero-App with normal user rights. The Problem is always when a privileged windows comes on front, Nitro-App disconnect.
I have several other USB HW, that has NOT this behavior . Also when I open in parallel IORegistryExplorer there is no disconnect shown. So I still believe there is something wrong with this behavior.
Now saying that, means - just don’t open the Terminal while I use Nitro-App.
Yes, my user’s name is next to it. This is why I think you have some custom change to system configuration, which could be the source of the problem, and we might just trying to workaround an OSX feature.
I have tried to reproduce the issue just now on two boxes, but I could not. What privileged windows do you mean? Could you provide some reproduction route?
In fact, I could not provoke disconnection with executing sudo bash in opened terminal window or unlocking editing Users & Groups (as in scenario from here).
What USB hardware do you mean (by class)? Are these communicating by HID with desktop application?
System applications might be divided to root (service) and user (GUI) side hence their behaviour might be different than NK App.
I see in the first post that you had same issue with earlier App version - 0.5.1. From that time the device detection algorithm has changed and it still is blocked by your OSX.
It is UID, PID, PPID, … , Program … So the login is done as root, while the rest is running under my normal user. Special commands ( like ps -e) that look also outside will run under root, while all other programs started in that Terminal will run under my user. So everything looks normal from my side, nor ?
When you now pull the terminal window into the fore front on macOS, you will get the disconnect message from the running Nitro-App.
yes, it is also HID class - like the Griffin PowerMate Button connected per USB. They also have a tray application. I never receive the message that
I also tried to chown Nitro-App to different users without a different result
Yepp, still the same issues
[Add-on]
When I first time try to open the encrypted part of the NK Storage, as it is not initialized, it will open the disk manager . And also here in the background I get the connected /disconnected messages. I assume the disk manager is also running under root.
I suspect the problem is that @Peacekeeper has Terminal > Secure Keyboard Entry turned on.
What happens is that on macOS, processes can request exclusive access to keyboards, e. g. for password entry. The window server then blocks any other process from receiving keyboard events or querying the devices (some background on the APIs: https://developer.apple.com/library/content/technotes/tn2150/_index.html). I assume the Nitrokey App uses some form of pinging the stick as a HID and is then lead to believe that the stick has been removed if the ping times out.
This is not limited to Terminal, btw. The system also uses this to protect standard password text fields in the UI, so every time an application asks for a password, the Nitrokey App goes bonkers, which is quite annoying.
I would really prefer the Nitrokey App to be less spammy regarding connection status, maybe something more subtle like a grey vs a coloured tray icon. The notifications are intrusive without really conveying any information, they catch a users attention only to tell them what they just did, and on top of that are wrong most of the time.
That’s it ! As soon as I uncheck the secure keyboard entry for the Terminal , it works switching back and forth terminal without any disconnection message.
Now saying that , I receive the message again, when I try to type into the edit field of this bulletin board . So as you and the Technote saying, there are multiple apps using this technic.
Nevertheless: the connection status seems to be relevant as the unlocking status of the NK Storage seems to get lost.
I will verify that from my side again , the NK Storage just crashed when I tried to read the whole content of a full 16GB SD. But seems to be a different topic/problem
Hi @kajaqfg72y !
Thank you for troubleshooting! I wondered why I could not reproduce this.
Actually the device vanishes from available devices list.
If it happens that often then indeed this would be useful. Reported as #254.
@Peacekeeper
On each connection device should be queried about its current state, so it should be safe to lose the connection temporary or even close and reopen the application. Do you have other experiences?
Could you register that on Github with a reproduction scenario please?
