Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App rejection: exhausted real (wall clock) time allowance of 19.85 seconds #15

Closed
Pranoy1c opened this issue May 27, 2019 · 2 comments
Closed

Comments

@Pranoy1c
Copy link

My AppDelegate's didFinishLaunchingWithOptions only has this code:

if let existingUser = Strongbox().unarchive(objectForKey: "currentUserAccount") as? [String:String] {
        Singleton.shared.currentUser = (existingUser["username"]!,existingUser["cookievalue"]!,existingUser["cookie"]!)
    }

In testing this has worked mostly fine. But sometimes I have noticed a bit slowness but haven't been able to consistently reproduce this.

Today, my app got rejected with this crashlog:

exhausted real (wall clock) time allowance of 19.85 seconds

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001f7dae0f4 0x1f7d96000 + 98548
1   libsystem_kernel.dylib        	0x00000001f7dad5a0 0x1f7d96000 + 95648
2   libdispatch.dylib             	0x00000001f7c13880 0x1f7bfc000 + 96384
3   libdispatch.dylib             	0x00000001f7c13d10 0x1f7bfc000 + 97552
4   libxpc.dylib                  	0x00000001f7e72a04 0x1f7e68000 + 43524
5   Security                      	0x00000001f8e83edc 0x1f8e58000 + 179932
6   Security                      	0x00000001f8e8445c 0x1f8e58000 + 181340
7   Security                      	0x00000001f8eda414 0x1f8e58000 + 533524
8   Security                      	0x00000001f8ed92f4 0x1f8e58000 + 529140
9   Security                      	0x00000001f8ed7c60 0x1f8e58000 + 523360
10  Security                      	0x00000001f8ed85f4 0x1f8e58000 + 525812
11  Security                      	0x00000001f8eda31c 0x1f8e58000 + 533276
12  Security                      	0x00000001f8ed6284 0x1f8e58000 + 516740
13  Security                      	0x00000001f8ed89dc 0x1f8e58000 + 526812
14  AppName                	0x00000001010af1b0 Strongbox.data(forKey:) + 405936 (Strongbox.swift:140)
15  AppName                	0x00000001010aeae4 Strongbox.unarchive(objectForKey:) + 404196 (Strongbox.swift:83)

It seems that the unarchiving is taking too long.

I read through a few issues on SO and keychain related slowness is apparently a common issue. This one in particular seemed interesting:

https://stackoverflow.com/questions/10536859/ios-keychain-not-retrieving-values-from-background

So I have changed kSecAttrAccessibleWhenUnlocked to kSecAttrAccessibleAfterFirstUnlock in Strongbox and am resubmitting the app to see if it goes through. Something you might want to change in the library too as kSecAttrAccessibleWhenUnlocked is too restrictive imo.

Docs say:

kSecAttrAccessibleAfterFirstUnlock Item data can only be
accessed once the device has been unlocked after a restart. This is
recommended for items that need to be accesible by background
applications. Items with this attribute will migrate to a new device
when using encrypted backups.

kSecAttrAccessibleWhenUnlocked Item data can only be accessed
while the device is unlocked. This is recommended for items that only
need be accesible while the application is in the foreground. Items
with this attribute will migrate to a new device when using encrypted
backups.

So kSecAttrAccessibleWhenUnlocked might cause issues for developers who try to access strongbox when the device is not unlocked (think of notification center widgets, notifications etc).

@granoff
Copy link
Owner

granoff commented May 27, 2019

Interesting. Thanks for pointing this out. You can, of course, pass in whatever accessibility value you like in your call to unarchive() as your needs require. I'll consider making the change permanent though.

@granoff granoff closed this as completed May 27, 2019
@Pranoy1c
Copy link
Author

@granoff Yes, I think for majority of the people, kSecAttrAccessibleAfterFirstUnlock is a better setting. Might be worth adding a note regarding this in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants