mirror of
https://github.com/yattee/yattee.git
synced 2026-10-23 13:12:53 +00:00
2d23820e14
Fifth review pass, which prompted measuring whether SecItemDelete can be conditioned on a value. It cannot: a delete issued with a deliberately wrong kSecValueData still returns 0 and removes the item, so there is no compare-and-delete and every check-then-delete is a race by construction. That measurement decides both fixes here. Adoption no longer rolls back its own write when the verification read comes back empty. The rollback could only ever be a blind delete of whatever occupied the key by then - including a credential synced from another device in the gap - and it would propagate. Nothing is deleted; no marker is written, so the account stays signed out and an ordinary sign-in recovers it. Legacy deletion re-reads immediately before deleting and aborts if the value moved, shrinking the window to a single call gap and catching a replacement that landed while the fingerprint was being computed. A residual race remains and is documented at the call site: closing it is not possible with these APIs, and never deleting would leave a credential the user explicitly removed sitting in their iCloud Keychain. The debug provenance report repeated the same nil-token ambiguity the scope logic was fixed for, reporting "no Apple account signed in" when iCloud Drive is merely off. It now reports the token as unavailable and shows CloudKit's account status separately, so a re-run cannot draw a false conclusion from it.