scptd bundle, if an AppleScripter wants to use your library in their codesigned AS app they must embed, and thus re-sign, your library and the libsqlite code contained within it, or else their app will no longer load it. If your sqlite AppleScript library keeps its own copy of libsqlite in its. apps that run Swift/ObjC/C++/etc code, requiring all of that code to be codesigned by the app’s author in order to run it, regardless of where it comes from. This would make sense as macOS is pretty strict nowadays w.r.t. Are you saying that a codesigned app can still load some (unsigned) AS libraries from /Library/Script Libraries and ~/Library/Script Libraries, but not if those libraries themselves use 3rd-party ObjC frameworks? I did see the word “framework” in your original post. (And it would be a serious bug if it was.) this would no longer work: MyApp.app/Contents/Libraries/Script Libraries/3rdPartyLib.scptdīut I don’t think that’s what you mean. The above sentence makes it sound as if embedding a 3rd-party library in your app’s bundle is now busted, meaning e.g. I’m talking about a script library within a (in this case notarized) app’s /Contents/Libraries/Script Libraries directory. It is what it is, and we just have to pay the bill now. But that’s the historical realities of business economics, 90s processing power, and the 80s not having a crystal ball. Mind, it’d have been infinitely less painful and messy had all this user-level security had been built-in from Day One of Personal Computing, instead of it now being retrofitted to free-for-all chaos several decades after. But it does right by the Users, a nice change from the traditional developer “I’m not responsible” policy. As I say, retrofitting it now is going to be painful. Tying the code to its authors is a step to making those authors answerable for their code’s behavior. Guarantee that if signed code is later on tampered with, that tampering is detected andĮnable software distributors (in this case Apple) to blacklist any program immediately on it being reported to contain malware and to provisionally suspend or permanently revoke the credentials of any developer found to be accidentally/deliberately malware so that all their other code is immediately blocked from running too. Knowing provenance is critical.Ĭodesigning itself does not guarantee that the code is safe and free of malware (although related processes such as notarization can include checks for some recognized naughties), as a malware author can always sign his own code. In essence, a code signature is a binding declaration by that software’s author: “I personally wrote this software, and I take responsibility for everything that it does.” To use a comparison: there’s a good reason why airport customs always asks if you packed your own suitcases, or if someone else packed them for you. So it’s good if Apple is now forcing the issue by requiring all code be signed before it can freely run on anyone’s machines but its authors’. It’s just that the programmer world is taking its sweet time to start addressing it, because it’s a monster they created and they know it will take a lot of hard work to fix now. Supply-chain attacks are not a new phenomenon. (Sad to say, but the only real growth industry for AppleScript &co these days is the malware market.) If you know of any official Apple docs mentioning it, please do share.Īn “all libraries must be signed” policy makes a lot of sense in light of recurrent supply-chain attacks, where malware authors insert malicious code, not into the apps themselves, but into the 3rd-party libraries used by those apps (and in the libraries used by those libraries, and so on). If so, I would not categorize that as a “failure” (which implies a macOS bug, to be reported and fixed) but as an intentional change in macOS’s security policy, part of Apple’s general movement toward requiring all executable code is codesigned.įWIW, I quickly skimmed the 12.5 security notes and didn’t see anything specifically about codesigning and AS libraries, but it does sound like an intentional tightening of security policy around scripting and automation in general, which is both needed and overdue. If I understand you correctly, what you’re saying is that as of 12.5 a codesigned app will not load (unsigned) libraries from /Library/Script Libraries and ~/Library/Script Libraries.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |