Code signing fail

I get an error message that code signing fails every now and then after I have opened applets in SD and tries to save them code signed. See screenshot below for the full error message.
This happens as a rule when I try to code sign applications that has not been code signed before (in that case often applets thad have been edited with Script editor before). But it also happens with applets that HAVE been code signed with SD before.
Does anybody know how to avoid this?
Or can it be a problem related to me using SD with Swedish as primary system language? I can’t see other threads about this problem – so it doesn’t seem to be an problem that affects everyone. And I have other problems that seems to be related to my choice if system language.
My workaround is to build a new applet from SD, then copying all code from the original applet, as well as the other stuff in the bundle such as script libraries and icons. Sometimes I have to do that process several times. Not that fun.
NOTE: The screenshot shows an error message named with a non-english letter. But I get the same error with apps named with a-z only as well.

Looking at my screenshot, I realize one could suspect Dropbox causing the trouble.
I have been syncing my many scripts and applets with Dropbox for many years, with no such trouble. But maybe Dropbox can create problems for code signed applets specifically?

I just discovered that cleaning the bundle from extended attributes solves the problem with saving it!
But is there a risk with doing that? This applet seems to work fine.

Extended attributes just aren’t allowed in codesigned bundles. if you’re asking if it can have side-effects, then yes, it can. For example, .scpt files can lose things like editor settings and QuickLook-ability.

(As part of its codesigning, Script Debugger removes extended attributes from every .scpt file in the bundle’s /Contents/Resources/ directory. Beyond those, it’s really your responsibility.)

As part of its codesigning, Script Debugger removes extended attributes from every file in the bundle’s /Contents/Resources/ directory. Do you have files elsewhere in the bundle? If not, I’d love to see an example where it fails.

1 Like

This happens to applets without files I have included.
If I include files, I always put them in the resources folder. Usually in a subfolder that I create (like /Contents/Resources/Files/), but never outside the resources folder.
I’ll be happy to share an example with you, Shane, the next time I have one.

What causing my signing trouble is the extended attribute attached to the bundle itself – if the file have been synced with Dropbox from one Mac to to another.

Removing that one makes the signed app savable (or rather, singneable) again:

Hemdata:~ jorgen$ xattr /Users/jorgen/Desktop/

:arrow_up: Applet refuses to be signed.

xattr -d /Users/jorgen/Desktop/

Hemdata:~ jorgen$ xattr /Users/jorgen/Desktop/

:arrow_up: Problem gone!

So, as I suspected, Dropbox syncing might be the root cause to my problem. After syncing some information in is not accepted. Noticable is maybe the fact that the name of user I log in as on each of the two Mac differs.

@ShaneStanley Attached is (73.4 KB) – as it was before I removed

Thanks, @Jost. I’ll see if we can remove extended attributes from the bundle as part of the code-signing.

1 Like

I use this AppleScript for code-signing anything that I don’t codesign in Script Debugger. It removes the extended attributes before doing the signing:

on open f
set filePath to POSIX path of f as string

if filePath ends with "/" then
	set filePath to text 1 thru -2 of filePath
end if

display dialog "I will codesign" & return & return & filePath & ". OK?" buttons {"OK", "Cancel"}
	do shell script "xattr -r -c " & quoted form of filePath with administrator privileges
on error err
	display dialog err
end try
	do shell script "codesign -s \"Developer ID Application: YOUR NAME HERE\" --deep -f " & quoted form of filePath
on error err
	display dialog err
end try
do shell script "touch " & quoted form of filePath

tell me to activate
display dialog "Codesigned" & return & return & filePath buttons {"OK"} giving up after 3

end open

1 Like

That could be very useful, @emendelson
I made a droplet to just remove the xattr that causes the problem here so that I can code sign it with SD. So if I run into the error message, I drop the affected app on the droplet and then it’s possible to save it code signed.

property xattrToRemove : ""
property rinsedPaths : {}

on open thePaths
		display alert "Xattr ’" & xattrToRemove & "’ will be removed from the choosen applications" buttons {"Cancel", "OK"} cancel button 1
		set rinsedApps to {}
		repeat with aPath in thePaths
			set posixPath to POSIX path of aPath
			set {fileName, fileExtension} to {name, name extension} of (info for posixPath)
				if fileExtension is not "app" then error posixPath & ": Not an application bundle"
				do shell script "xattr -d " & xattrToRemove & space & quoted form of posixPath
				set end of rinsedApps to fileName
			on error errT
				display alert "Nothing was changed for " & fileName message errT
			end try
		end repeat
		if rinsedApps is not {} then
			set AppleScript's text item delimiters to ", "
			set rinsedAppsString to "" & rinsedApps
			set AppleScript's text item delimiters to ""
			display notification rinsedAppsString subtitle "" & (count rinsedApps) & " apps were rinsed"
			delay 0.1
		end if
	on error number -128
	end try
end open

Of cause it would be more convenient if SD could do that for us.

This little codesign-checking utility still seems to work in High Sierra, though I haven’t tested it in Mojave:

1 Like

Just for the record, @emendelson:
• AppCheckerLite crashes every time in Mojave
• The AppleScript you provided doesn’t work, at least not for me. It tells me that my applet has been is codesigned – but it’s not.
For me it works fine to use my droplet (code above) to remove the specific xattr from my applets when the problem occurs before using SD to save/codesign the them.
So don’t bother. I just thought you might want to know.

That’s good to know, @Jost. Thank you.

It’s unfortunate that these things aren’t working for you, but I just tried out RBAppCheckerLite and my own code-signing AppleScript in Mojave. Both worked perfectly. I code signed an app with my script, and checked it with RBAppCheckerLite. No problem with either, as you see from the screen shot. Perhaps something is wrong with your system?

Right, @emendelson.
RBAppCheckerLite works on a machine with Mojave I use for tests.
However, it shows me an error for every script I try it with, shown below.
I wonder if that is related to the kind of certificate I use for my apps. When signing in SD the choice is displayed as “3rd Party Mac Developer Application:…” not as "Developer ID Application:… ".
Maybe I can ignore this warning? My script solutions are not distributed for use outside my workplace (Gatekeeper is not stopping them from running here) and the code signing works to fill the needs we have for it: keeping away repeated allow-script-to-use-application-so-and-so-dialogs in Mojave.

@Jost. I have no idea. I’ve never tried code-signing with a 3rd Party Certificate. Maybe someone else knows?