Find password even with no username supplied in OSX backend

[maarten0912]

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

[jaraco]

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]

Any thoughts on my questions?

[maarten0912]

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]

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

• kSetAttrAccount = ''
• kSetAttrAccount = None
• no kSetAttrAccount

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]

Interesting - it appears as if that logic was added when the API was migrated from C to ctypes. The C logic also translated None to the empty string.

This all makes me think the logic is more likely incidental than necessary... and support for None was minimal. Indeed, there are no tests for it and the type spec indicates a string is required.

A couple of requests:

• Can you add a test or two to cover the new expectation?
• Can you verify what happens when None is passed explicitly for kSecAttrAccount?
• Can you unify the logic across all methods (get/set/del/...)?