Crash on launch: Keychain returned unexpected status code: -25295

[zcohan]

How frequently does the bug occur?

Seen twice

Description

A user reported that my app is crashing on launch. I just launched a new version with MongoDB Realm Sync support. My app does have the keychain sharing entitlement enabled.

Stacktrace & log output

2021-09-13 17:20:12.993 Soulver 3[6599:275887] *** Terminating app due to uncaught exception 'RLMException', reason: 'Keychain returned unexpected status code: -25295'
*** First throw call stack:
(
0   CoreFoundation                      0x00007fff2050483b __exceptionPreprocess + 242
1   libobjc.A.dylib                     0x00007fff2023cd92 objc_exception_throw + 48
2   Realm                               0x0000000105c42ae7 -[RLMApp initWithId:configuration:rootDirectory:] + 951
3   Realm                               0x0000000105c42c78 +[RLMApp appWithId:configuration:rootDirectory:] + 158
4   Realm                               0x0000000105c42d23 +[RLMApp appWithId:configuration:] + 20
5   Realm                               0x0000000105c42d47 +[RLMApp appWithId:] + 19

Can you reproduce the bug?

Not yet

Reproduction Steps

No response

Version

10.13.0

What SDK flavour are you using?

MongoDB Realm (i.e. Sync, auth, functions)

Are you using encryption?

No, not using encryption

Platform OS and version(s)

macOS 11.5.2 (20G95)

Build environment

No response

[jsflax]

Do you have anymore information for us? Seems to be a rare error and could be related to key generation.

[zcohan]

I have receieved a second report of this crash at launch, from a different user:

2021-09-18 22:21:43.849 Soulver 3[4109:63955] *** Terminating app due to uncaught exception 'RLMException', reason: 'Keychain returned unexpected status code: 100013'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff204a11db __exceptionPreprocess + 242
	1   libobjc.A.dylib                     0x00007fff201dad92 objc_exception_throw + 48
	2   Realm                               0x0000000103ba2ae7 -[RLMApp initWithId:configuration:rootDirectory:] + 951
	3   Realm                               0x0000000103ba2c78 +[RLMApp appWithId:configuration:rootDirectory:] + 158
	4   Realm                               0x0000000103ba2d23 +[RLMApp appWithId:configuration:] + 20
	5   Realm                               0x0000000103ba2d47 +[RLMApp appWithId:] + 19

The user tried the following troubleshooting steps to no avail:

Reboot
Uninstall and reinstall the app form the App Store
Uninstall the App Store version of the app; install the app from the Soulver website
Uninstall using CleanMyMac; separately reinstall and test the App Store and website apps

Is there any other information you'd like me to request from this user? The product is currently unusable for him, as it crashes on launch due to this issue.

[zcohan]

Correction: both the Mac App Store version and direct version of the app crash on launch for these customers due to the "Keychain returned unexpected status code" exception. So it appears Realm Sync simply can't be used on Macs with certain keychain states.

Can also confirm this still issue is still present in the latest build of the SDK (10.15.1)

[tgoyne]

Manually deleting the keychain entry may work around whatever's wrong, which can be done by opening Keychain Access, searching for "Realm Sync Metadata Key" and deleting all of the matching things (it'll probably be just one). A more extreme workaround would be to set the REALM_DISABLE_METADATA_ENCRYPTION environment variable to any non-empty value, which will result in us not touching the keychain at all (and storing the user's access and refresh tokens unencrypted on disk).

The only guess I have about what the problem could be is something related somehow to updating to new versions of the app somehow resulting in the OS deciding that it's no longer the same app and should no longer have access to the keychain entry created with a previous version? Unfortunately the keychain file isn't exactly something we can reasonably ask for a copy of to inspect...

[zcohan]

Thanks Thomas. I don't think that theory is correct, as this version of my app is the first that connects to MongoDB Realm Sync, so there shouldn't be a keychain entry from a previous version.

One of my customers experienced an error in another Mac OS application, which produced the following logs:

Error Domain=NSOSStatusErrorDomain Code=-25295
"errKCInvalidKeychain / errSecInvalidKeychain: / The keychain is not valid."
[Error] [main] > macOS error description: The specified keychain is not a valid keychain file.

Following these instructions (https://help.queens.edu/hc/en-us/articles/205937040-How-to-Resolve-Mac-OS-X-Keychain-Problems) he was able to "Reset Default Keychains" and fix the problem.

The bottom line here is that the keychain can be in an unexpected state on certain Macs. Perhaps that's a fatal error for Realm, and throwing an exception is appropriate. However Realm Sync is an optional feature in my application: I can simply disable the feature, or warn the user that they need to reset the keychain if they want to enable it.

Would you please update the SDK to allow me to handle this error appropriately on my end, rather than crashing the app on launch?

[tgoyne]

Yeah, we definitely should be properly returning the error to the caller and if nothing else that part is a bug.

[zcohan]

Can I please have some more guidance/support on this issue? It is rendering my product unusable for 30+ of my customers, who are experiencing a crash on launch due to it.

There are at least three 'unexpected status code' exceptions being reported by Sentry.io:

• Keychain returned unexpected status code: 100013
• Keychain returned unexpected status code: -128 (the most common)
• Keychain returned unexpected status code: -25295

It's not reasonable to assume that the keychain is always in an "expected" state on all macOS accounts. Throwing exceptions like these without giving client applications like mine some way to recover from this error is not a good approach.

[tgoyne]

What behavior would you prefer here? Deleting the metadata Realm and forcing the user to log in again is a straightforward way to handle the case where we can't read the existing keychain entry, but are able to write a new one. If we can't write to it, would you want to get an error (probably via the sync error handler callback?), or for us to just skip encrypting the metadata Realm and store the user's access token unencrypted? I think the latter would be easy to implement.

[zcohan]

I'd be fine with storing the user's access token unencrypted, or returning an error. The main thing I need is to not hit an unrecoverable exception that crashes the app. I don't have any means to contact customers running into this issue, so unless they contact me themselves, their experience is that the app just doesn't open.

[tgoyne]

realm/realm-core#5329 should make all of the reasonable reasons for the keychain to be inaccessible result in an unencrypted metadata realm (possibly forcing the user to log back in if the keychain was previously accessible but no longer is).

[jhoughjr]

This seems to eb the issue I have.
I enabled catalyst and ran on my Mac, m1 and got
*** Terminating app due to uncaught exception 'RLMException', reason: 'Keychain returned unexpected status code: -34018'
Does it every time, works fine on the iPhone.
I have no clue what would be wrong with my keychain and as stated above, it would be nice to have an actionable error or more info. Ive already spent 30 mins trying to learn about this error.
Unless apple is syncing crap from 2018 when I used realm, I dont see why realm would make assumptions about keys in a keychain on first launch.
1 problem CoreData doesnt have.

[jhoughjr]

looks on line 274 of RLMApp.
.... It appears enabling keychain sharing resolves the issue, disregard my comments.
I am surprised that info did not show up in pages of google on the subject.