When we compared the old version of the library with the new one, the only difference we saw was in the types of cryptographic hashes being applied. The library that was failing was one that we had recently recompiled. Everything appeared right – Apple’s diagnostic tools like codesign and spctl reported no problems. Normally, when an application is exported from Xcode, all of the libraries inside it are signed. It’s important that they be code signed as well, since the code inside them gets executed. Libraries are chunks of code which are designed to be reusable across applications. The issue had to do with something related to code signing – the operating system was reporting an error with one of the libraries that EditReady uses. That seemed pretty strange – it worked on versions of the operating system older and newer than 10.10, so we would expect it to work there as well. We recently ran into an issue in which a new test build of EditReady was working fine on our development machines (running MacOS 10.12, Sierra), and was working fine on the oldest version of MacOS we support for EditReady (Mac OS X 10.8.5), but wasn’t working properly on Mac OS X 10.10. It can be pretty complicated to get it all right though. This is a powerful tool for preventing forgery and hacking attempts. Code signing is the process by which a cryptographic “signature” is embedded into an application, allowing the operating system to confirm that the application hasn’t been tampered with. Most Mac developers have, at one time or another, struggled with an issue related to code signing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |