New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty string username works in python 3.11 but returns None in python 3.12 (keyring 24.3.1) #668
Comments
On my Windows system, I see consistent behavior across Python versions:
I can confirm in credential manager that the password is being stored with an empty username. I'm unsure why it's not able to be retrieved. |
I'm not confident that empty usernames was ever supported. I searched the code and there are no tests guaranteeing that empty usernames work, so if they happened to work, it was a lucky accident. In bc34083, I added such a test, and it's failing right away (on Windows only), seemingly due to a failure to delete the password on cleanup. More troubleshooting is called for. Can you tell me more about your use-case? How long have you been using empty usernames? Do you know why I've been unable to replicate your findings? What version of Python 3.11 do you have? Can you confirm that you have the latest keyring on both Python 3.11 and 3.12? |
Hi Jason,Thanks for your answers. I use conda forge to create my environments under windows 10 64 bits. Python 3.11 is 3.11.8Python 3.12 is 3.12.2Using Keyring 25.0.0, I now observe the same behavior as you do which is that the password is saved but cannot be retrieved when the username is an empty string. Weirdly, I downgraded keyring to 24.3.1, and I cannot retrieve the password under python 3.11 as well. Which I swear I could when I wrote that ticket. So I am quite puzzled. I am perfectly happy to go with the lucky accident use case. When I started using the keyring library a while ago, I wrote a little pytest file on its behavior to see what was working and what was not and familiarize myself with the library. And among those tests, I parametrized the user to be an empty string username.I wanted to see if that was working as this could be useful if I wanted to save a password for something that did not have a notion of username (maybe a global password for a software). Furthermore, on windows, as you probably know, the credential manager is already user specific. It turns out that I never used an empty username string in my keyring usage, but that little test has now started to fail. It’s fairly easy to circumvent so I completely understand if you just want to call this “unsupported”. But since my little test had started to fail, I thought I would report it in case that was a supported feature. I hope this answers all your questions and I’ll let you decide what to do with this. Many thanks. On Mar 23, 2024, at 13:07, Jason R. Coombs ***@***.***> wrote:
I'm not confident that empty usernames was ever supported. I searched the code and there are no tests guaranteeing that empty usernames work, so if they happened to work, it was a lucky accident. In bc34083, I added such a test, and it's failing right away (on Windows only), seemingly due to a failure to delete the password on cleanup.
More troubleshooting is called for. Can you tell me more about your use-case? How long have you been using empty usernames? Do you know why I've been unable to replicate your findings? What version of Python 3.11 do you have? Can you confirm that you have the latest keyring on both Python 3.11 and 3.12?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Describe the bug:
Storing a password with an empty string "" username in windows 64, returns None with python 3.12.
To Reproduce:
All on windows 64, set up an environment with python 3.12 and keyring 24.3.1. Set a password with an empty string username "". Retrieve the password -> None.
Expected behavior
Doing the same thing with python 3.11, the password is retrieved.
Environment
The text was updated successfully, but these errors were encountered: