search

Nitrokey / nitrokey-app

Nitrokey's Application (Win, Linux, Mac)
https://www.nitrokey.com/
287 stars 55 forks source link

HOTP generated keys: copy/paste issues with keepass 2 under wayland #432

Open glasl opened 4 years ago

glasl commented 4 years ago

Expected behaviour

when generating a hotp key, it is copied to the clipboard and can be pasted in the keypass 2 OtpKeyProv plugin interface in a wayland session.

Current behaviour

In a wayland session, when generating a hotp key, it is copied to the clipboard, but cannot be pasted in the keypass 2 OtpKeyProv plugin interface. You can paste the clipboard content to e.g. a text file, copy it again and paste it in the OtpKeyProv plugin interface. When starting a xorg session, behaviour is as expected.

Steps for reproduction

Preconditions

Wayland Session, Device reinserted, Application just started, Keypass 2 with OtpKeyProv started

Steps

  1. Generate HOTP key, key is copied to clipboard
  2. paste in Keepass 2 OtpProvKey Plugin interface
  3. key is not pasted
szszszsz commented 4 years ago

Hi! Thank you for the report!

This sounds like a general Wayland problem, and package maintainers might want to look at it. Would have to check that.

Have you looked at our Snap and AppImage/Flatpak releases? These have own libraries shipped, which could potentially fix the issue.

glasl commented 4 years ago

Thanks for the quick reply. I will gladly do further tests, also for issue #431 .

I didn't manage to find a flatpak package of nitrokey-app, where is this located (flathub, ...)? Edit: I found it in 1.4 release.

glasl commented 4 years ago

I could not retest this issue as neither AppImage nor Flatpak package would detect the Nitrokey Pro v2. This is despite closing all related processes.

Side note: flatpak would open the process 'bwrap' twice - is this the expected behaviour?

szszszsz commented 4 years ago

Side note: flatpak would open the process 'bwrap' twice - is this the expected behaviour?

cc @enleth

quiescentnexus commented 4 years ago

note: flatpak would open the process 'bwrap' twice - is this the expected behaviour?

It's not and I can't think of any reason it would do that. We're not doing anything weird or unusual in the build process.

glasl commented 4 years ago

To come back to the topic:

I got the AppImage working and tested the issue with the v1.4 AppImage. The copy/paste issue is not present!

In the flatpak built the issue is still present though.

Could this be an issue with the QT/GTK Theming?

glasl commented 4 years ago

Okay, I guess I found the underlying issue:

running: $ nitrokey-app results in: $ qt.qpa.wayland: Wayland does not support QWindow::requestActivate() and the application behaving as described.

running:

$ export QT_QPA_PLATFORM=xcb
$ nitrokey-app

works flawless. So my guess is the build environment is not defined correctly as X11 for linux builds.

Fixing the build environment will definitely fix #431.

glasl commented 3 years ago

It seems to me, there is no progress in making the code Wayland compatible/ abandoning deprecated QT5 functions.

Current workaround for me is editing the .desktop entry /usr/share/applications/nitrokey-app.desktop:

Exec=nitrokey-app -platform xcb

This sets the desktop environment variable for tor the Nitrokey-App to use XWayland instead of Wayland. It does not fix the underlying issue.

Maybe this is helpful to other users until it's fixed properly.

PureTryOut commented 2 years ago

I find it strange that you can at least copy it to some other programs, as I can't copy it anywhere. Even worse, according to KDE Plasma's clipboard applet, nothing gets added to the clipboard at all.

And well, for me changing the Qt platform from Wayland to XCB doesn't help either. Only thing that does is making the context menu appear in the middle of the screen rather than next to the tray icon.

So right now I literally have to switch to an X11 session if I want to use a HOTP key, and then switch back to Wayland when done. Not fun at all.

The application could definitely use some modernization to work properly on Wayland platforms.

szszszsz commented 2 years ago

Bumping this ticket up, as the upcoming Ubuntu 22.04 will use Wayland by default for all graphic cards

szszszsz commented 2 years ago

Test results:

To do:

PureTryOut commented 2 years ago

Although it shouldn't make a difference please also test with alternative UI's, at least KDE Plasma. That's where the clipboard is broken for me.

szszszsz commented 2 years ago

Will do, thank you for the suggestion! Indeed I have done tests with the default WM only - Gnome.

AndrewAmmerlaan commented 1 year ago

I find it strange that you can at least copy it to some other programs, as I can't copy it anywhere. Even worse, according to KDE Plasma's clipboard applet, nothing gets added to the clipboard at all.

And well, for me changing the Qt platform from Wayland to XCB doesn't help either. Only thing that does is making the context menu appear in the middle of the screen rather than next to the tray icon.

I have the same problem. It only works for me if 1) nitrokey-app is launched with QT_QPA_PLATFORM="xcb" and 2) the application you are pasting into is also launched with QT_QPA_PLATFORM="xcb". If you do it like this then you'll see that after pasting the code now does show up in the KDE Plasma clipboard widget.

If you access the clipboard form a pure wayland application (i.e. an application not launched with QT_QPA_PLATFORM="xcb" or GDK_BACKEND=x11) it will not paste the generated one-time password and it will not show up in the clipboard.

So current workaround would be, e.g.:

PureTryOut commented 1 year ago

That works! :scream: Damn that makes Nitrokey so much more useful for me, I hated having to switch sessions constantly GitLab logged me out again and I had to get my TOTP key again. Thanks, it's bad that it's needed but it makes it usable at least again.

szszszsz commented 1 year ago

As another workaround, a nitrocli can be used to get HOTP code from the CLI:

If you have suggestions how to adjust it for Wayland to make this problem away please let us know.

PureTryOut commented 1 year ago

@szszszsz have you had a chance to test on KDE Plasma yet? It's one of the two most used DE's and it being broken completely on Wayland out of the box is terrible. I love that I have a workaround now so I don't have to relog to X11 every time but having to use it is silly, and the workaround is literally forcing the window to run in XWayland mode.

I don't personally know why it's broken, sorry, but it really needs some investigation.

01stakanov commented 4 months ago

This should really be addressed as Wayland is now standard for notebooks and Plasma under opensuse TW, I filed a bug https://bugzilla.suse.com/show_bug.cgi?id=1219019 before the bug owner found out it was actually an implementation issue. This can cause loss to the user, does cost time that is better invested elsewhere. Currently still broken on Wayland with Operating System: openSUSE Tumbleweed 20240206 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.7.2-1-default (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon Pro W5500 Product Name: X570 Phantom Gaming 4