Closed JonasKruckenberg closed 2 years ago
This has been resolved (we kept the security list-keychains -d user -s $keychains
usage as it is responsible for setting the keychains
to the search list (the confusion happens because a command named list
actually sets
something). Here's the command help output:
$ security list-keychains help
Usage: list-keychains [-d user|system|common|dynamic] [-s [keychain...]]
-d Use the specified preference domain
-s Set the search list to the specified keychains
With no parameters, display the search list.
Display or manipulate the keychain search list
Describe the bug
Related to #4008.
As of eaf9e5a9a6c0959be46d2969a423ef7689ea9225 the tauri bundler runs the following command during code signing on macos:
security default-keychain -s $KEYCHAIN_ID
, this command is fine when code signing in a CI runner that get's discarded afterwards anyway, but seriously not fine if you try to code sign locally. As many apps use the default keychain to store access tokens, this will make it impossible to access any apps and log into new ones until the user restarts the app.I resolved this issues with PR #4053, but ran into another issue:
The
codesign
command (the one that does the actual signing) can't find the certificate in the keychain unless the keychain is primed withsecurity default-keychain
orsecurity list-keychain -d user -s $KEYCHAIN_ID
first. This bug is absolutely unexplainable to me and I haven't found any reasonable explanation other than this is some sort of syncing issue in macos.This issues is intended to be a tracking issue for this problem and is referenced in the code for future reference.
Reproduction
error: The specified item could not be found in the keychain.
Expected behavior
To not require priming a command with a completely unrelated command?
Platform and versions
Stack trace
No response
Additional context
No response