Code-signing in SD7

Script Debugger
#4

I have noticed that Code Signing appears to not work when trying to sign with my Developer ID in Script Debugger.

I have successfully used my Developer ID to sign applets using the codesign command-line tool as well as Script Editor.

After saving an code signed applet with Script Debugger, I don’t see a _CodeSignature folder in the Contents folder of the application bundle.

Using the Receigen application the analyze the applet, I don’t see a Certificate Chain listed for the Signature or anything that should be there for a code signed app.

When trying to codesign a non-signed applet exported by Script Debugger using the command-line tool, I get the error:

/Blah/Blah/Blah.app: code object is not signed at all
In subcomponent: /Blah/Blah/Blah.app/Contents/Script Debugger.plist

As a test, I was able to successfully codesign an applet of the same script exported by Script Editor (after running xattr -cr on the app bundle).

#5

Did you try with a simple new script? Have Console open at the same time, and see if anything appears there.

#6

Just gave that a try. Same exact behavior. Didn’t see anything relevant to code signing in the Script Debugger messages in Console.

Tried codesign in Terminal again and got the same error. Deleted Applet.app/Contents/Script Debugger.plist and then did codesign from Terminal again and it worked…

#7

I just did another test adding an arbitrary file into the App bundle instead of Script Debugger.plist and codesign in the Terminal failed with the same error.

I poked around in the man codesign and tried the --deep option… and it worked!

My app bundle with an arbitrary file included signed properly and then I exported a fresh applet from Script Debugger and was able to sign it properly using the --deep option in codesign

PS. I’m not an expert on Code Signing, I’m not positive --deep is the correct solution, there may be another way. I just know that it worked in my basic testing.

PPS. But, this information from from man codesign does look relevant: Code nested within bundle directories must already be signed or the signing operation will fail, unless the --deep option is given, in which case any unsigned nested code will be recursively signed before proceeding, using the same signing options and parameters.

#8

Script Debugger uses the --deep option.

So let’s try again. Create a new applet, don’t add anything to Resources, and try to sign it. Does it work?

Also, what version of the OS are you running?

#9

I just realized it’s not as simple as --deep myself because I tried exporting a run-only script as an applet and having Script Debugger sign it on export. That also did not result in a signed applet and there was no extra Script Debugger.plist in that applet. That applet was completely unmodified by me in any way.

I’m running 10.13.4

#10

OK, so save an applet from Script Debugger, then try signing it from Terminal using --deep and --force.

#11

I had this same issue. The problem is Script Debugger’s placing its Script Debugger.plist file directly inside Contents.

Please look at Apple’s TN2206 > Nested Code > Table 3. You see Contents is the first item in Table 3. And then under that table it says:

These places are expected to contain only code. Putting arbitrary data files there will cause them to be rejected.

I wondered why Info.plist is OK, but apparently Info.plist is handled as a special case:

Bundles must have their Info.plist in the proper location. For app bundles, this is in Contents.

So, there you go, it seems to be a design mistake in Script Debugger. That Script Debugger.plist file should be in Contents/Resources. Should I file a bug somewhere?

I should add that I’m not using Script Debugger’s Code Signing feature. I am new to Script Debugger and did not know about that feature until I stumbled on this forum. I am codesigning with an old Perl script that invokes Apple’s codesign tool. But I think you’d get the same problem either way.

#12

Consider it filed. The question, though, is why it works fine here (and elsewhere – others are using it successfully) and not there.

@jerrykrinock, what version of the OS are you running?

Also, could you confirm that it signs OK if you do a run-only export? Thanks.

#13

I am using 10.13.5; saw this in Beta 4 and Beta 5.

The answer to your second question is yes and no.

If I do File > Export Run-Only Script, and in the export sheet, set Code Signing to my Developer ID Application: ID, it appears to work, and if I check it with codesign --verify, it passes.

But if I do File > Export Run-Only Script, and in the export sheet, set Code Signing to Don’t Code Sign, and then later attempt invoke codesign to sign its applet, I get the same error as when I attempt to sign the regular .app:

/Users/jk/Documents/AppleScripts/Sheep Systems Trouble Zipper Run-Only.app/Contents/MacOS/applet: code object is not signed at all
In subcomponent: /Users/jk/Documents/AppleScripts/Sheep Systems Trouble Zipper Run-Only.app/Contents/Script Debugger.plist

One more data point for you. If, after I File > Save my .app in Script Debugger, I dig in and move that Script Debugger.plist from Contents into Contents/Resources, and then invoke codesign on the applet, it works:

/Users/jk/Documents/AppleScripts/Sheep Systems Trouble Zipper.app/Contents/MacOS/applet: signed app bundle with Mach-O universal (i386 x86_64) [applet]

I suppose the dichotomy could be explained by this remark which is also in that documentation:

While strict compliance with these rules may not affect your app today, anything that doesn’t meet these requirements note may be rejected by code signing verification … at any point in the future without notice.

In other words: Don’t try to understand Apple’s rules. Just obey them strictly. :slight_smile:

#14

Yes, I understand Apple’s capriciousness in these things. I just want to be certain about the cause, given that I’m running the same version of the OS as @Pico, with no problems.

Thanks for the further testing.

1 Like
#15

capriciousness

Nice! +1❤︎ for English vocabulary.

#16

So I’m still troubled by this.

I fired up a Mac with 10.13.5 beta 5, downloaded a fresh copy of Script Debugger 7.0.2, saved an applet, turned on code signing with my ID, saved again, and ended up with properly signed app.

Anyone else following along who has tried code signing and can/can’t succeed?

#17

Sorry for not getting back to this sooner. I just started poking around with this again.

And, I just realized the major difference in my workflow!

I have been working from a .scpt or .applescript source file. Then, using “Save A Copy As…” to export a code signed application. Doing that flow is when I am not getting a code signed application.

From reading your last reply, I tried what it sounds like you are doing, which is saving an application and then editing the application in Script Debugger with code signing turned on. This technique does properly code sign the app! But, I would not like to keep my source files as applets.

To reiterate:

Open a .scpt or .applescript and “Save A Copy As” an Application with Code Signing: The exported App is not Code Signed as it was set to be in the Save dialog.

But, open that exported Application in Script Debugger, turn on Code Signing in the File menu and then Save the Application again: The App is properly Code Signed.

#18

I’m a bit confused. When you choose Save A Copy As…, the Code Signing popup in the save dialog is disabled, so you can’t code sign at that point.

23%20am
Screen Shot 2018-05-22 at 10.16.23 am.png850×602 58.2 KB

#19

Ah! Well, maybe that is the actual bug I am encountering.

The Code Signing drop down IS enabled when I Save A Copy As an Application!

If it is not actually supposed to be enabled, why is it not allowed to code sign when exporting as an app?

CodeSignEnabledOnSaveACopyAs
CodeSignEnabledOnSaveACopyAs.png1064×634 93.2 KB

#20

For some more info, the Code Signing option in the Save dialog is Enabled for me when saving as a “Application (Apple)”, “Application (Enhanced)”, as well as “Compiled Script Bundle”.

On another related note, I was messing around with Code Signing an Applet opened in Script Debugger (which works properly). I turned Code Signing back off in the File menu and saw that the signature was not removed from the Applet. I think it may make more sense to remove the signature (which can be done with “codesign --remove-signature”) when Code Signing is turned off for an Applet that was previously signed rather than leaving an invalid signature in place.

#21

My apologies. There’s an expert preference that sets the default value for code signing on export only, and I’d forgotten I’d changed it to true.

So I can now reproduce the problem.

#22

Thanks for all the feedback — the issue will be addressed in a forthcoming maintenance release. In the meantime, please use the workaround of a second save.

FYI, the Script Debugger.plist file turned out to be a red herring.

#23

Was this issue fixed? I am able to codesign without issue when manually saving out an application but I am encountering an error while trying to AppleScript Script Debugger to save out codesigned, run-only apps. The Save and Close (with saving options) functions are automatically reverting all saves to Do Not Codesign.

Attaching a screen video to show it in action (sorry that the volume is low).