Mac codesign and suite.xml

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Mac codesign and suite.xml

I am dealing with a security settings issue with my Netbeans installer.  The project Netbeans installer fails when it attempts to unpack its contents.  The problem is the project exe/app that is wrapped inside of the Netbeans installer, or in the case of a Mac install, a zip file.  It is the internal project's exe/app that is not signed via codesign so it fails upon installation.
I found in the suite.xml file the place where the Windows .exes are created (32-bit/64-bit).  After the Windows exes are created I am able to call a python script, within suite.xml, and perform a codesign routine.  It successfully signs the executables and then continues running the suite.xml script.  The Window's Netbeans installer is now able to install my app onto user's desktop without issue.
The problem, and most critical, is with the Mac build.  I am attempting to sign a Mac .app generated from Netbeans.  The ant script that Netbeans calls contains a symlink tag.  I don’t believe I can code around, unless, there is another tag that can be used?  Anyway, once the app is created I make a python call to execute codesign.  The .pfx file that I have appears in the “My Certificates” category of the Keychain Access Manager.  Here is the command that I execute:

codesign –s “My Company Name” mypath/myapp.app
The message being returned is as follows:
codeSignCommand: ['codesign', '-s', 'My Company Name', '/Users/myname/NetBeansProjects/myapp.3.development/myapp/dist/myapp.app']
after call
/Users/myname/NetBeansProjects/myapp.3.development/myapp/dist/myapp.app: the main executable or Info.plist must be a regular file (no symlinks, etc.)

Perhaps there is an alternate way I can use to sign my .app file.  Any help/direction would be greatly appreciated.  I need to come up with a signed build ASAP.  Many of our Mac users are beginning to upgrade their system to Sierra OS.  They are no longer able to install this app.  The temporary workaround is to have them install using parallels.  Needless to say, this is not an acceptable workaround for them.
I've been in contact with my company's codesign certificate vendor.  They offered the following solution, where prior to signing I remove the symlink and replace with the actual file.  The psuedo commands they offered were:
rm /Applications/myapp.app/Contents/PlugIns/jdk1.8.0_131.jdk/Contents/MacOS/libjli.dylib
cp /Applications/mypp.app/Contents/PlugIns/jdk1.8.0_131.jdk/Contents/Home/jre/lib/jli/libjli.dylib /Applications/myapp.app/Contents/PlugIns/jdk1.8.0_131.jdk/Contents/MacOS
The commands they provided need adjusting to match whichever folder/file is symlinked. The idea is to replace the symlink with the actual file to allow for codesign to process.
I have an idea of the directory/folder location used by the "rm" command, but I don't know what to use for the first parameter used by the "cp".  Below is the code used by suite.xml that establishes the symlink:
    <target name="build-mac" depends="build,build-launchers" description="Builds a ZIP distribution of the suite, launchers, and selected modules from the platform.">
        <mkdir dir="${dist.dir}"/>
        <mkdir dir="${dist.dir}/${app.name}.app"/>
        <mkdir dir="${dist.dir}/${app.name}.app/Contents"/>
        <mkdir dir="${dist.dir}/${app.name}.app/Contents/MacOS"/>
        <mkdir dir="${dist.dir}/${app.name}.app/Contents/Resources"/>
        <property name="app.icon.icns" value="${harness.dir}/etc/applicationIcon.icns"/>
        <copy file="${app.icon.icns}" tofile="${dist.dir}/${app.name}.app/Contents/Resources/${app.name}.icns"/>
        <copy todir="${dist.dir}/${app.name}.app/Contents/Resources/${app.name}/bin">
            <fileset dir="${build.launcher.dir}/bin/" />
        <copy todir="${dist.dir}/${app.name}.app/Contents/Resources/${app.name}/etc">
            <fileset dir="${build.launcher.dir}/etc/" />
        <subant genericantfile="${harness.dir}/suite.xml" target="copy-cluster" inheritrefs="true">
            <property name="dest.dir" value="${dist.dir}/${app.name}.app/Contents/Resources/${app.name}"/>
            <property name="nbexec.dir" value="${dist.dir}/${app.name}.app/Contents/Resources/${app.name}"/>
            <property name="build.dir" value="${suite.build.dir}"/>
            <resources refid="zip.platform.clusters"/>
        <copy todir="${dist.dir}/${app.name}.app/Contents/Resources/${app.name}/${app.name}">
            <fileset dir="${cluster}"/>
        <copy verbose="true" failonerror="false"
        <delete file="${dist.dir}/${app.name}.app/Contents/MacOS/${app.name}"/>
        <symlink link="${dist.dir}/${app.name}.app/Contents/MacOS/${app.name}" resource="../Resources/${app.name}/bin/${app.name}"/>
        <chmod file="${dist.dir}/${app.name}.app/Contents/Resources/${app.name}/bin/${app.name}" perm="755"/>
        <chmod dir="${dist.dir}" includes="${app.name}.app/Contents/Resources/${app.name}/platform*/lib/nbexec" perm="755"/>
        <copy file="${harness.dir}/etc/Info.plist" tofile="${dist.dir}/${app.name}.app/Contents/Info.plist">
                <replacestring from="$${app.name}" to="${app.name}"/>
                <replacestring from="$${app.version}" to="${app.version}"/>
                <replacestring from="$${app.title}" to="${app.title}"/>
                <replacestring from="$${app.icon}" to="master.png"/>
                <replacestring from="$${branding.token}" to="${branding.token}"/>
I have come across other articles that discuss signing a Mac .app.  One involves a significant amount of work (http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html).  I would have to modify all the build-impl.xml files.  Plus, there is some guessing on my part as to what the properties assignments would be in the example.  The Mac OS and ant scripting are new to me.  My main concern with this solution is the impact it would have on my Windows build.  Plus, I am not sure if it will work.
Thank you.