Closed Ryu-ga closed 9 months ago
Looks good to me, other than the still painful file-based management of keys
I think we need to try a binary-based solution instead. Not ideal, but should be less painful
@Ryu-ga Since the r_Ref fix is in-tree now, please rebase your PR
Looks good to me, other than the still painful file-based management of keys
I think we need to try a binary-based solution instead. Not ideal, but should be less painful
That's good idea. And there is need to find out more similar keychain file name generator to apple's one.
@Ryu-ga Since the r_Ref fix is in-tree now, please rebase your PR
I rebased it.
That's good idea. And there is need to find out more similar keychain file name generator to apple's one.
They don't use individual files. They use a SQLite 3 database.
That's good idea. And there is need to find out more similar keychain file name generator to apple's one.
They don't use individual files. They use a SQLite 3 database.
You're correct; I meant that before transitioning to db-based structure for PlayChain we require more distinguishable file names because certain keychain items cannot be fully separated for now.
we require more distinguishable file names because certain keychain items cannot be fully separated for now
Well to be clear, there are already collisions now, just that it doesn’t affect us too much. Also, fyi, we cannot use straight up SQLite 3. It is not available by default in AppKit/UIKit
https://github.com/PlayCover/PlayCover/issues/1359
First, there is a need for a response from SecItemDelete with
errSecItemNotFound
in some iOS framework, as it works well on iOS. Second, the linked iOS app had a memory issue with ARC andSecCreateKeyWithData
, I think it is weird that it require Unmanaged.passRetained but it crashed every time with unknownObjectReleasing every time end of SecItem methods in the app, and SecItem-methods do not have responsibility for releasing the referenced object*result
. [https://developer.apple.com/documentation/security/1401659-secitemadd]