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.
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 com.apple.FinderInfo 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/Example.app
com.apple.FinderInfo
com.apple.metadata:kMDLabel_b3absjiwxjzeuxvqprreqljvbu
com.dropbox.attributes
Applet refuses to be signed.
xattr -d com.apple.FinderInfo /Users/jorgen/Desktop/Example.app
Hemdata:~ jorgen$ xattr /Users/jorgen/Desktop/Example.app
com.apple.metadata:kMDLabel_b3absjiwxjzeuxvqprreqljvbu
com.dropbox.attributes
Problem gone!
So, as I suspected, Dropbox syncing might be the root cause to my problem. After syncing some information in com.apple.FinderInfo 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 Example.app (73.4 KB) – as it was before I removed com.apple.FinderInfo
Thanks, @Jost. I’ll see if we can remove extended attributes from the bundle as part of the code-signing.
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"}
try
do shell script "xattr -r -c " & quoted form of filePath with administrator privileges
on error err
display dialog err
end try
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
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 : "com.apple.FinderInfo"
property rinsedPaths : {}
on open thePaths
try
activate
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)
try
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
activate
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
return
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:
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.
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?