search

jaraco / keyring

MIT License
1.24k stars 152 forks source link

Find password even with no username supplied in OSX backend #655

Open maarten0912 opened 10 months ago

maarten0912 commented 10 months ago

Find a keyring password even if no username is supplied in the OS_X backend

jaraco commented 9 months ago

Can you tell me more about the motivations for making this change? Under what conditions is a null versus empty username relevant for macOS? What compatibility considerations should we make for users relying on the current behavior (None -> "")?

jaraco commented 5 months ago

Any thoughts on my questions?

maarten0912 commented 5 months ago

Any thoughts on my questions?

The motivation for the change is because I wanted to find a keyring based only on its name (kSecAttrService). In my use case, the account of the keyring (kSecAttrAccount, but called username above) was not known and not important. The API will give the first result in case there are multiple keyring with the specified name, which was what I wanted in my case.

I would say that the library should work for querying empty usernames (account name is "") of keyrings and also for querying without a username (account name is None). Unfortunately, I do not see what we can do for users relying on the current behaviour.

jaraco commented 5 months ago

I don't have a good understanding of the differences between the following scenarios:

I'm guessing kSetAttrAccount of None is invalid.

More importantly, we'll probably want to align with other backends to provide an expectation at the keyring level of what should happen for empty or null usernames.

Since there do not appear to be any tests protecting the existing behavior (None → <empty string>), we should at least trace that code and determine when that logic was added to see what the motivation might have been for it.

jaraco commented 3 weeks ago

I have some news regarding this issue. In #668 and #687, I'm exploring completely deprecating support for empty usernames across all keyrings to provide consistency. The guidance in that change is that all clients of keyring should always pass a non-empty username, even if it's just some static value. Some backends, like Windows, don't behave properly if the username field is empty, and I want to try to avoid inconsistencies (so an application doesn't test on Linux or Mac and then find that users on Windows get a bad experience).

If support for empty usernames is valuable to you, can you comment in #668 as to why? Thanks.