Fixed keyring unlocking.

[dkosmari]

The previous method for unlocking the keyring wasn't working on my systems, so I changed it to use service.unlock_sync().

[osmank3]

Thanks for your contribution. I could not face with your problem in any of my test systems. I tried your code, it is working extensions settings page but not working in extension's main ui. So I did not merge. If you share your systems specs I will test and develop this extension.

[dkosmari]

I cannot reproduce your test case. Here are the cases I tested, with GNOME 44 on Xorg:

Test 1:

• Login password: no
• Keyring password: no

Test 2:

• Login password: yes
• Keyring password: no

Test 3:

• Login password: no
• Keyring password: yes

For tests 1 and 2:

• "Unlock keyring" on the menu does not update the menu, it keeps the "Unlock keyring" option.
• "Unlock keyring" in extension preferences does not update the UI. The Keyring does unlock, and the "otp-key-test" entry remains in the keyring, but the extension fails to detect it. Restarting Gnome Shell is necessary for the extension to see the keyring is unlocked. After manually re-locking the keyring, the extension fails again, still leaving the "otp-key-test" entry in the (now unlocked) keyring, but not detecting it's unlocked. A restart on Gnome Shell is needed again.

My PR fixes this case. At no point it fails to update the menu or the preferences window, after the "Unlock keyring" option is used. It either detects the keyring is correctly unlocked, or the "Unlock keyring" does the expected thing, and the menus/preferences UI gets updated correctly.

For test 3:

Extension fails to start with the error "defaultCol is null". There's no default keyring, because there's no login password. Creating a default keyring, the error changes to:

JS ERROR: Extension otp-keys@osmank3.net: TypeError: otp is null
                                                   OtpMenuItem@/home/nologinpass-keyringpass/.local/share/gnome-shell/extensions/otp-keys@osmank3.net/extension.js:53:13
                                                   _fillList/<@/home/nologinpass-keyringpass/.local/share/gnome-shell/extensions/otp-keys@osmank3.net/extension.js:161:28
                                                   _fillList@/home/nologinpass-keyringpass/.local/share/gnome-shell/extensions/otp-keys@osmank3.net/extension.js:160:27
                                                   _init@/home/nologinpass-keyringpass/.local/share/gnome-shell/extensions/otp-keys@osmank3.net/extension.js:119:14
                                                   ButtonBox@resource:///org/gnome/shell/ui/panelMenu.js:11:1
                                                   PanelMenuButton@resource:///org/gnome/shell/ui/panelMenu.js:97:4
                                                   Indicator@/home/nologinpass-keyringpass/.local/share/gnome-shell/extensions/otp-keys@osmank3.net/extension.js:101:1
                                                   enable@/home/nologinpass-keyringpass/.local/share/gnome-shell/extensions/otp-keys@osmank3.net/extension.js:231:27
                                                   _callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:196:38
                                                   loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:398:32
                                                   async*_onInstallButtonPressed@resource:///org/gnome/shell/ui/extensionDownloader.js:294:35
                                                   Async*addButton/<@resource:///org/gnome/shell/ui/dialog.js:130:41

This is clearly a bug elsewhere in the code, and my PR changes nothing.

[osmank3]

OK, I will test your Test 1-2 cases with Gnome version 44.

About Test 3 case you can set any keyring to default keyring with seahorse or you can wait for a feature which will be added for choosing default or selected keyring for saving otp keys in a later release.

[osmank3]

OK, I was able to reproduce the error.

However there is a slight issue! There is no phrase to say for the passwordless login part, but the reason for keeping the OTP code on the keyring comes from the necessity of encrypting and hiding the code. When you leave the keyring without a password, anyone accessing your system can easily take over your OTP code. This situation goes against the purpose of using OTP. Therefore, I will not make any changes for Test 1 and 2 cases.

As mentioned in the previous message, for the Test 3 case, I am considering adding an option to utilize a default or desired collection on the keyring through the extension's settings in the future.

[dkosmari]

There's literally an API to unlock the keyring, yet you're trying to rationalize your clown code by saying I'm not allowed to keep the keyring without a password. I'll just maintain my fork then, my OTP codes will never be safe with clown code.

[osmank3]

You are free to develop the project in your own fork; open-source license is there for that. Best regards...