Use the system keyring instead of python to store user credentials

[IkelAtomig]

Please use the system keyring such as Kwallet or Gnome keyring. It is annoying the app always ask for password on rebooting the system, I login to the app everytime.

This was never a problem in the old app.

[Anonymous941]

For me, it always prompts for a password to create a new keyring, so I think this is a very annoying bug

[IkelAtomig]

For me, it always prompts for a password to create a new keyring, so I think this is a very annoying bug

I don't get what you mean by the keyring here. But it went too far and asking for a password whenever I open the app or close it and re-open it.

This exists in both Fedora 39 and 38. In the old app, It used the system's keyring. No problem was at all there. I don't get why use a external service to manage data when there is already one available.

[IkelAtomig]

A temporary solution I found. You login when the app asks you to login. Then logout and relogin. After that, It shouldn't ask for credentials again.

This seemed to be what worked for me when this issue came in Fedora 38.

[antermin]

Apparently the app uses org.freedesktop.secrets to store Proton account data (username, access token, etc.), and I am able to use KWallet or KeePassXC for this purpose.

For VPN connection, it seems that network-manager-applet / plasma-nm is needed.
On KDE, plasma-nm requires the use of KWallet for VPN credentials.

[Anonymous941]

Copying my comment on #4:

The problem is that it requires logging in every time the app is quit:

1. I reboot the computer or quit the app
   When this happens, the following is logged just before exiting:

2023-10-28T18:00:19.520283 | proton.vpn.app.gtk.widgets.headerbar.menu.menu:200 | INFO | UI.DIALOG:QUIT | Yes
2023-10-28T18:00:19.522838 | proton.vpn.connection.states:120 | WARNING | CONN:WARNING | DISCONNECTED state received unexpected event: Down
2023-10-28T18:00:19.523318 | proton.vpn.app.gtk.services.reconnector.reconnector:98 | INFO | VPN reconnector disabled.
2023-10-28T18:00:19.523518 | proton.vpn.app.gtk.services.refresher.client_config_refresher:76 | INFO | Client config refresher disabled.
2023-10-28T18:00:19.523672 | proton.vpn.app.gtk.services.refresher.server_list_refresher:81 | INFO | Server list refresher disabled.
2023-10-28T18:00:19.523811 | proton.vpn.app.gtk.services.refresher.vpn_data_refresher:141 | INFO | APP.VPN_DATA_REFRESHER:DISABLE | VPN data refresher service disabled.
2023-10-28T18:00:19.645674 | asyncio:1758 | ERROR | Task was destroyed but it is pending!
task: <Task pending name='Task-5' coro=<TCPConnector._resolve_host() running at /usr/lib/python3/dist-packages/aiohttp/connector.py:880> wait_for=<Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.10/asyncio/futures.py:385, Task.task_wakeup()]> cb=[TCPConnector._create_direct_connection.<locals>.drop_exception() at /usr/lib/python3/dist-packages/aiohttp/connector.py:1157]>

2. I then restart the app
   This line is logged only once, if I restart the app again without logging in, it doesn't appear:

2023-10-28T18:01:16.144833 | proton.vpn.connection.vpnconnector:185 | INFO | CONN:STATE_CHANGED | Disconnected (initial state)

3. The GNOME or KDE keyring prompts me for a password to create a new one, every time
4. I now must enter my Proton username and password again, and since this requires Internet, I have to disable the killswitch manually

[IkelAtomig]

I don't know how this is related but it asks for VPN Credentials at time even when internet connection is solid.

4. I now must enter my Proton username and password again, and since this requires Internet, I have to disable the killswitch manually

Same happens for me. But I didn't check for logs.

Apparently the app uses org.freedesktop.secrets to store Proton account data (username, access token, etc.), and I am able to use KWallet or KeePassXC for this purpose.

For VPN connection, it seems that network-manager-applet / plasma-nm is needed. On KDE, plasma-nm requires the use of KWallet for VPN credentials.

I am pretty sure. If you see the credentials in your keyring. It means it is the data stored by Old app. The new app now stores its data in python keyring.

[antermin]

I am pretty sure. If you see the credentials in your keyring. It means it is the data stored by Old app. The new app now stores its data in python keyring.

I am sure that the credentials in the keyring are stored by the new app:

1. The old app has been purged completely
2. I deleted the old wallet and KeePassXC entries
3. I tested the new app with a fresh wallet and database
4. KeePassXC displays access notifications whenever I open the new app (when the app gets Proton account credentials and log in)

Installed packages:

proton-vpn-gtk-app 4.1.0-1
python-proton-core 0.1.15-1
python-proton-keyring-linux 0.0.1-1
python-proton-keyring-linux-secretservice 0.0.1-1
python-proton-vpn-api-core 0.20.1-1
python-proton-vpn-connection 0.11.0-1
python-proton-vpn-killswitch 0.2.0-1
python-proton-vpn-killswitch-network-manager 0.2.0-1
python-proton-vpn-logger 0.2.1-1
python-proton-vpn-network-manager 0.3.0-1
python-proton-vpn-network-manager-openvpn 0.0.4-1
python-proton-vpn-session 0.6.2-1

python-proton-keyring-linux and python-proton-keyring-linux-secretservice work well on my Arch + KDE Plasma 5 environment.

My KWallet preferences:

• Everything unchecked (except "Enable the KDE Wallet subsystem")
• Wallet unlocked automatically on login

[IkelAtomig]

In Kwallet is it under Secret Service ?

[antermin]

I have disabled "Use KWallet for the Secret Service interface" since I am currently using KeePassXC for Secret Service.

However, in my testing, there is no problem if I use KWallet for Secret Service (and disable KeePassXC's Secret Service function).

[Anonymous941]

Could this be a conflict between gnome-keyring-daemon and KWallet? Try running:

sudo chmod -x /usr/bin/gnome-keyring-daemon
sudo killall gnome-keyring-daemon

And rebooting (I didn't need it but it can't hurt). After doing this, I disabled KWallet's secret service integration and enabled KeePassXC's. Then it finally stopped prompting me!

[antermin]

Currently the binary packages (Fedora and Debian) of python-proton-keyring-linux-secretservice have hard-coded gnome-keyring as dependency.

Maybe it will be a good idea to change that so that KDE users won't have to install it, and to avoid keyring conflicts?

[calexandru2018]

Hey all. As @antermin points out we currently only support Gnome-keyring as a backend for the keyring service. Actually if you take a close look at python-proton-keyring-linux you can see that we depend on the keyring package.

Edit: Hit post prematurely 😓

Since we had some headaches with the previous client (being agnostic of backend) with the current design we decided to create specific back-end packages for either gnome and kwallet (we haven't worked on kwallet though yet as we have a very limited bandwidth and we have many other things to add/improve).
But (and a big one) it is worth noting that kwallet has a good amount of drawbacks.

@IkelAtomig your data should be stored in the gnome keyring and it should not be prompting you. What distro are you using ? we've tested this only on distros that run gnome (because that's the only thing that we officially support atm, although it should work on KDE).

[IkelAtomig]

@calexandru2018 I use Fedora 39 with KDE. And I my wallet is unlocked automatically during boot without any issue.

[Anonymous941]

I have a theory. The problem on one computer mysteriously appeared when I switched to zsh.

@IkelAtomig Are you using zsh?
@antermin @calexandru2018 Are you using bash?

[antermin]

@Anonymous941

Yeah, I am using bash.

[Anonymous941]

Is it possible then that it adds an important environment variable to .bashrc, but not .zshrc?

[IkelAtomig]

@Anonymous941 I have no idea about .zsh. In my home directory I see .bashrc only.

[calexandru2018]

@Anonymous941 it shouldn't matter. I've used it in manjaro with .zsh and had no issues. Problem is Kwallet, please read the links I provided to arch wiki.

[IkelAtomig]

@calexandru2018 - I don't get the problem with KWallet. It is already unlocked automatically at login.

[t0mii]

If i set a password for my default keyring it works, if i set empty passwort for the keyring the app deletes the entry in the keyring everytime at launch. wtf

[Anonymous941]

If i set a password for my default keyring it works, if i set empty passwort for the keyring the app deletes the entry in the keyring everytime at launch. wtf

Is this the issue?? This actually might be, and I can't even open the keyring in the GNOME manager after I lock it

[mcwillzz]

If i set a password for my default keyring it works, if i set empty passwort for the keyring the app deletes the entry in the keyring everytime at launch. wtf

Having the same issue. Debian 12, with auto-login and no password set for the user logging in.

I set the password for the keyring to be blank, and it recreates the keyring on every reboot.

If I set a password it is fine, but I do not want to have to log in to my server to enter a password if I decide to reboot it...

[calexandru2018]

Hey all, could you please send issue reports through the app so we have some logs on this please ? I talked internally to our QA and we're a bit unsure why this is happening with gnome backend (can't reproduce on our side on gnome backends), it is expected with KDE as kwallet is a bit more tricky. Please refer to this ticket in the submission: #35

[mcwillzz]

Hey all, could you please send issue reports through the app so we have some logs on this please ? I talked internally to our QA and we're a bit unsure why this is happening with gnome backend (can't reproduce on our side on gnome backends), it is expected with KDE as kwallet is a bit more tricky. Please refer to this ticket in the submission: #35

Report sent through the app, thank you for investigating! I was having issues headless so I switched from an LXC to a true VM and installed Debian Gnome just to use the VPN... and then ran into all of this after that. In my case, getting the CLI working without desktop environment dependencies would be ideal.

[IkelAtomig]

I prefer the config files right now because of this issue which is more stable.

[calexandru2018]

@mcwillzz could you please clarify on the following

with auto-login and no password set for the user logging in.

So you don't need to type your pass to login, but WDYM with not password set for the user logging in ? From my experience you always need a password, unless I'm missing something here.

[calexandru2018]

Closing this and any further discussions should be on #30