Apple Kremlinology suggests they'd be hesitant to provide that information with a paper trail. There would be a lot less mysteries in the Apple world if they did.
That said, you could probably get an answer at WWDC, if you find one of the code signing guys at the lab and corner them.
Same here for my app, but I’m not sure it’s so curious. It’s unlikely I would have realized it was a phantom update vs a regular update if I weren’t the developer of the app.
> It turns out that AirPort Utility is code signed with the exact same certificate chain as the old version of Airfoil Satellite. So if there is a problem with the old signing certs, whether expiration or something else, the problem still exists with AirPort Utility. Presumably this fact would also rule out the (highly unlikely) possibility of private key compromise.
If an Apple key was compromised, why would they go through the effort of resigning old third party apps but not one of their own?
In Windows software signing, the notBefore/notAfter specifies when the app has to be signed. If the certificate (or issuing certificate?) has a certain magic flag, which most do, the signature will be valid forever as long as it was made within the validity window.
To know whether the signature is made within the validity window (or at least, not backdated), a countersignature from a timestamping service is added. If the countersignature or the flag in the cert is missing, an expiring cert will prevent the application from starting (Mumble had that problem), but if both are present, the signature is valid forever.
No idea if OSX handles it the same way, but it would make sense if they did.
So, does anyone with a jailbroken iOS device want to decrypt the .text sections and bindiff them? I'd be very curious to see what the actual changes are.
16 comments
[ 2.8 ms ] story [ 22.0 ms ] threadSo , somebody knows the reason of the phantom updates?
That said, you could probably get an answer at WWDC, if you find one of the code signing guys at the lab and corner them.
Its curious that both of us worked on the apps receiving the phantom update
> It turns out that AirPort Utility is code signed with the exact same certificate chain as the old version of Airfoil Satellite. So if there is a problem with the old signing certs, whether expiration or something else, the problem still exists with AirPort Utility. Presumably this fact would also rule out the (highly unlikely) possibility of private key compromise.
If an Apple key was compromised, why would they go through the effort of resigning old third party apps but not one of their own?
Hmm. What is the point of notBefore/notAfter constraints if they don't do anything?
To know whether the signature is made within the validity window (or at least, not backdated), a countersignature from a timestamping service is added. If the countersignature or the flag in the cert is missing, an expiring cert will prevent the application from starting (Mumble had that problem), but if both are present, the signature is valid forever.
No idea if OSX handles it the same way, but it would make sense if they did.
I can't figure out another reason myself… I know it is never a compiler bug, but it could be something less serious.