We've had this head scratcher for a long time now. The app is sparkleapp.com, a website builder, it has a bulit-in FTP client that stores the password in the keychain. We use SSKeychain to store and retrieve the password.
A random selection of users will lose their password after the app update. In this case the non-appstore version of our app Sparkle (not sandboxed) updates is via the Sparkle updater framework (humor me).
Previous topics suggests the DR determine whether the Keychain will allow the updated app to access the keychain information. I ran a the update here and the result of the two versions appears to be an identical DR:
Duncans-MacBook-Pro:tmp duncan$ codesign -d -r - /Users/duncan/auto/builds/Sparkle\ 2.8.7.app/
Executable=/Users/duncan/auto/builds/Sparkle 2.8.7.app/Contents/MacOS/SparkleNonMAS
designated => anchor apple generic and identifier "eu.riverdesign.sparkle" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "8W892L9Q36")
Duncans-MacBook-Pro:tmp duncan$ codesign -d -r - /Users/duncan/auto/builds/Sparkle\ 2.8.7\ updated\ to\ 2.8.8.app/
Executable=/Users/duncan/auto/builds/Sparkle 2.8.7 updated to 2.8.8.app/Contents/MacOS/SparkleNonMAS
designated => anchor apple generic and identifier "eu.riverdesign.sparkle" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "8W892L9Q36")Does the lack of access on some of our user Macs mean their update failed to produce identical DR?
Unfortunately this seems to happen to unsophisticated users, it's really hard to ask them to try things for me. Questions I have asked suggest they don't get a keychain unlock prompt.
Sorry I'm really stuck and have no idea how to troubleshoot this.
