Indeed, it looks like package has not been rebuilt for latest version link.
Yes, installation from source should be straightforward. It needs Qt5.5 (0.6.3 worked on Qt4).
Quick compilation guide below, (details are in readme).
git clone https://github.com/Nitrokey/nitrokey-app.git --recursive
cd nitrokey-app
mkdir build
cd build
cmake ..
make -j2
#install is optional - needed only for udev rules to be copied, could be done manually too
make install
Edit: just checked and the issue is not occurring on v1.1, Ubuntu 16.10, Storage v0.45 - clipboard was correctly cleared.
Edit: without udev rules (allowing to use USB devices by user) it might not be possible to use the Application without root privileges
It looks like you have a C++ compiler not supporting C++14 standard. Is it possible to install GCC 5.0 or Clang 3.4 (possibly 3.3?) on your workstation and use it for compilation?
I have had no luck compiling the source from git, even if I use the gcc v5 compiler. However I found an rpm with nitrokey-app v. 1.1 at https://github.com/Nitrokey/nitrokey-app/releases and installed that successfully.
So, reverting to my original question about clearing the clipboard, I find that the copied password is still available on the clipboard after more than 15 minutes. And yes, I am sure I’m using version 1.1.
I have registered an issue from your description here: #263. Could you write please a reproduction route for it? Just to be sure the issue is fixed or not.
Also added mentioned enhancement as #262
You have wrote before that you are using other OSes too. Is it occurring on Mint?
Yes, I am using unicode. I have also tried to add a test password with only ASCII-characters, and it remains on the clipboard still after 30 minutes.
I don’t have any PC with Mint anymore. I have, however, downloaded the source from git onto my Manjaro laptop. It compiled without problems. But nitrokey-app shows the same behavior. The password remains on the clipboard.
Hey,
I tested today on OpenSuse 42.3 and could not reproduce the behavior. The Clipboard got deleted after two minutes.
I tried
@30lW’A@m+JDb%+4q<Zj
áśdḱĺfj
Both worked fine. So I guess it is something else. Can you still try these two passwords to make sure it has nothing to do with the exact passwords you are use?
Please post exact reproduction path on which the issue occurs on your side. Please also post environment details for formality: OS version, App version, device model and version (you can follow issue template if you would like to). Do I understand correctly this issue is occurring for you on both v1.1 and v0.6.3?
Hi!
I’m very sorry to respond so late. As I can see there is a difference between v1.1 and v0.6.3. In v.1.1 an entry of blanks are added to the clipboard, which means that you cannot directly paste the password to anywhere else. This does not happen in v0.6.3. However, in v1.1, the password remains in the clipboard (klipper) history in clear text, and it can be easily retrieved. It is possible to get around this behaviour by configurating klipper to only hold one entry. But that would cripple klippers functionality severely. I can delete individual entries in the klipper history, and that is what I would prefer the Nitrokey app to do as well.
ah… so you are using Klipper? Well Klipper is meant to cache the clipboard, isn’t it? I don’t see how we can circumvent this. Maybe there is a cli which let us deleting the last entry. As the Nitrokey App is done to work on many different systems and setups I am not sure whether this would be a good idea though
Can you have a look, if everything works as intended when Klipper is turned off?
And you are saying, that the password is not copyied in Klipper when using 0.6.3 but it is when using 1.1?
Klipper is the default clipboard manager in openSuse. I assume that most (all?) Linux distributions are using some clipboard manager. And I would guess that keeping several entries are part of the basic functionality of that. If there are other managers (for KDE) that is easier for the Nitrokey app to interface against, I’ll be happy to try one out.
The difference between v0.6.3 an 1.1 is that the password remains on top of the clipboard stack in v0.6.3, ie. it can be pasted in to any application for ever as long as you don’t copy some other item into the clipboard, in which case it get pushed back in the history stack. But remains available and readable. In v1.1 of the Nitrokey app it seems as a dummy entry of several blanks are copied to the clipboard so that it will not longer be possible to immediately use ctrl-v to paste the top entry somewhere else. But the original password is still in the clipboard stack and can be selected. I assume that some malicious program could read the clipboard history and thereby access password information.
Now it is clear where the issue came from. Actually I believe no clipboards managers are delivered (=shipped by default) in Gnome and Unity (perhaps KDE only?) and this is why we have not realized what is this issue about at the beginning.
This is actually quite fine observation. The workaround for it would be copying 20 (or more if the manager has higher entries count limit) random strings to the clipboard to overwrite its history. Actual interfacing with the clipboard manager to remove the specific entry (and save the rest of the memorized copied chunks) will be rather troublesome. I hope this solution will satisfy you.
In my (default) configuration I have 7 entries. But this can be configured to many more.
A google search shows that there are many clipboard managers for both KDE and Gnome, as well as other desktops. I also find some discussions about an API for management of the clipboard, including one attempt to do a cross platform API.
For myself I’ve made a habit of manually deleting passwords from the clipboard, so I can live with the situation - although I probably will forget that the one time it really matters
there surely are, but KDE may is the only DE which enables such things per default (or did in the past). In my KDE times I used this for a long time but stop eventually (without particulary reason). Afterwards I never stumbled over such functions again (at least as auto-enabled feature).
If there is a solution which applies on different programs of this kind, that would be great. Maybe we can have look how other security related programs are managing this. I am wondering if password-managers like KeePass are affected as well and if not why…
On my computer KeePassX behaves a little bit different. There is an option “Clear clipboard after sec” (in my case 15 sec). And it will do exactly that. After 15 sec it is no longer possible to use ctrl-V to paste the password into another app. But the entry remains on top of the klipper history stack, and it can be retrieved from there. I guess this is fairly much the same as the way Nitrokey app is doing things. This may boil down to a problem with clipboard managers rather than with the clipboard itself. But given the proliferation of clipboard managers on many platforms, this remains a concern for anybody dealing with security issues.
