Oops never mind the second one, I misread the documentation. Reading from the keychain without specifying the group should scan all groups…
> On Sep 22, 2021, at 7:54 PM, Miguel Arroz <[email protected]> wrote: > > Hi, > > (Now without HTML…) > > I never wrote code touching the Keychain on iOS, but did on macOS using the > iOS behaviour (kSecUseDataProtectionKeychain set to true). > > There are two things in that class that I would look into: > > - Line 40: items[kSecAttrAccessGroup] = FileManager.appGroupId > > If I understand correctly, this ends up being "group.$(APP_ID_IOS)”. I’m a > bit surprised this doesn’t need the Team ID before “group”, as it definitely > needs that in macOS. > > - The openReference() function, because it’s not setting the same > kSecAttrAccessGroup parameter when reading. The documentation mentions what > happens when it’s not set > (https://developer.apple.com/documentation/security/ksecattraccessgroup), I > wonder if that changed (intentionally or due to a bug in iOS 15): > >> If you don’t explicitly set a group, keychain services defaults to the app’s >> first access group, which is either the first keychain access group, or the >> app ID when the app has no keychain groups. > > None of these explain why the tunnel keeps working after upgrading to iOS 15 > (if the on-demand flag is set), as I would expect the Network Extension to > hit the same problem, as it goes through the same Keychain code. But maybe > the behaviour is slightly different than when it’s running through the app > for some reason. It could explain why re-building the tunnels would work from > then on (although then I would expect the extension to *not* be able to read > them). So all this may be just a red herring. > > Hope it helps somehow. > > Regards, > > Miguel Arroz > > > >> On Sep 22, 2021, at 6:34 PM, Jason A. Donenfeld <[email protected]> wrote: >> >> Hey folks, >> >> Small update: I've managed to update a fresh 14 device to 15 using the >> latest build, and things are broken still. >> >> On the plus side: >> - The new build no longer deletes VPN profiles when the corresponding >> keychain references are unresolvable, so if there's any chance of >> recovery in a next build, it won't ruin those chances. >> - Now that I can reproduce it, I can hammer away at trying to fix this >> directly. >> >> On the minus side: >> - The fact that a keychain reference goes stale during an update from >> 14 to 15 sounds solidly like an Apple bug, rather than any sort of API >> misuse. >> - I'm skeptical that there'll be a workaround, and if there is, it >> will probably be pretty ugly. >> >> If anyone knows the SecItem APIs well, the file in question is: >> https://git.zx2c4.com/wireguard-apple/tree/Sources/Shared/Keychain.swift >> >> So, I guess I'll jump into this in full force now. Here we go... >> >> Jason >
