stephencelis
Storing password in keychain conflicts with other tools (security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.)
I was stuck in a loop of security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain. similarly to what was described in https://github.com/stephencelis/ghi/issues/189. The issue was that another tool, fue also wants to store a password in the keychain and the latter doesn't support multiple labels for the same website.
Repro
To reproduce the problem do security add-internet-password -a [your username] -s github.com -l Whatever.
security add-internet-password -a dblock -s github.com -l Whatever
~$ security add-internet-password -a dblock -s github.com -l Whatever
~$ ghi config --auth
Enter dblock's GitHub password (never stored): ⠠security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
✔
Two-factor authentication code: ...
✔︎ Token saved to keychain.
~$ ghi list
fatal: --local can only be used inside a git repository
⠐security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
#
Authorization required.
Please run 'ghi config --auth <username>'
~$
Why does this happen?
Let's store a password.
~$ security add-internet-password -a dblock -s dblock.org -l Label1
~$ security add-internet-password -a dblock -s dblock.org -l Label2
security: SecKeychainAddInternetPassword <NULL>: The specified item already exists in the keychain.
Now find it.
~$ security find-internet-password -a dblock -s dblock.org -l Label1 -w
...
~$ security find-internet-password -a dblock -s dblock.org -l Label2 -w
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
~$ security find-internet-password -a dblock -s dblock.org -l -w
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
This makes it impossible for 2 separate tools to store different passwords for github.com?!
Workaround if you use fue
- Delete the fue token from OSX keychain
- Configure GHI with
ghi config --auth - Fue will work too because it looks for a password without a label
What's next?
One improvement would be that ghi doesn't look for the password using a label. This way it will find any password for github.com. That's what fue does, but it's far from ideal since the token required for ghi needs write permissions (fue is read only and needs the least privilege so any token will work).
So I am not sure what the best way to fix this is? I wrote fue so it could get out of the way, but it's not really a general solution.
Hi @dblock! I'm not really maintaining this library anymore (I've handed duties off to other folks but am not sure how active they are). I don't have time to make any changes, but perhaps the solution is to set a more general keychain item that doesn't collide? I'd be happy to add you as a collaborator if you'd like to take that one!
