Name collision when Quest ID is equal to username

[prydom]

When a Quest ID is the same as the system username the Quest password concatenated with the username was treated as the default user. Of course no such user existed so no password would be retrieved from the keyring.

I have fixed this in a forthcoming pull request.

[hkpeprah]

I will check this later (and go over keyring's changelog). As I understand it, the issue is when the Quest ID and the username are the same, the users list is stored under the current user's name under the Marmoset program header, but if this matches the user's Quest ID, then there's a conflict. That's a good catch :+1:

[prydom]

Exactly correct. I spent no time with keyring; I only upgraded it because gnome keyring only worked with a newer version than what was required. It's probably a good idea to do that due diligence.