User Profile

Hi,I am in a bit of an double corner case here. I have a package which consists of ONLY command-line executables. This package is a number of Unix utilities AND it uses a traditional Unix style build system (autoconf/make). We used to distribute this as a gzipped tar file, but obviously this fails when it comes to Catalina and notarization. This package consists of a number of executables, some shared libraries those executables link against, and a few dylibs that those applications load at runtime using dlopen(). Our plan is to provide a traditional MacOS installer package going forward.I have honestly been trying to do my homework, and I think I've got most of the mechanics down. I have an Apple Developer certificate, and I've been able to codesign executables and shared libraries, and ship them off to be checked by the notarization service, and that works. I have read all of the guides I can find about codesigning and notarization, including Signing a Mac Product For Distribution (thank you for that!). But I haven't QUITE seen something that covers my specific case, in that I am building a package OUTSIDE of Xcode AND it is not an application bundle (the build system is large and incorporating it into Xcode is just TOO much of a heavy lift right now). So I am trying to understand everything that I need to do.Specifically, my questions are:Do I need to compile an Info.plist into every bit of code? I understand HOW to do that, using the -sectcreate option to the linker, but it wasn't clear to me if that is required. Is it only required for executables, or both executables and libraries? The implication that I need to compile an Info.plist came from here https://eclecticlightdotcom.files.wordpress.com/2019/06/notarizecmdtool.pdfThere is a warning in the codesign man page under the --identifier option that says, "It is a very bad idea to sign different programs with the same identifier". Okay, fine. But it ALSO says that either gets the identifier from the Info.plist or the filename if that option isn't present. I am concerned that if I compile in the SAME Info.plist into every bit of code then all of the code gets the same identifier, and that would be "very bad". Obviously I can add the --identifier and --prefix options to codesign, but it wasn't clear if there were any implications in doing that.I was originally under the impression that I had to bundle up the binaries separately to get notarized, but it SOUNDS like that all I need to do is once I create the installer package, with everything signed inside of it, AND I sign the installer package, I can just submit the installer for notarization and that will cover everything?I know I can use spctl to check the status of executables, but it doesn't seem like that works for dylibs. Is that correct?Thanks for any help you can provide.--Ken

Hi,Thank you, eskimo and John, for replying to my earlier message; I was able to get all of my tools successfully signed and notarized! However, this brought up a question from a fellow group of software developers and I wanted to ask people here.The fellow developers are distributing a proprietary Java application. The Java runtime they use is open-source, but their proprietary bits are in the .jar files. This application is not distributed to the Mac store, but only made available to their customers.They complained to me about the hassles of Gatekeeper on Catalina (because they knew I was working on in for the software I am working on, and their software package uses components of what I am working on). Their primary concern is that they didn't want to upload their .jar files to Apple since that's their proprietary bits.But, this brings up my question. This is again a bit of a corner case, because it's a little opaque to me at least how the connection between the file you submit with altool and the notarization ticket applied with stapler all works. My understanding is the only true Mach-O binaries that they ship is the Java runtime and all of the associated components. One thing that has been mentioned is that you can upload a zip file to be notarized. Would it be possible to correctly sign the Java runtime, just zip up the runtime components, submit THAT for notarization, and then once notarization is complete they can use stapler to staple the notarization ticket to their package (which includes the proprietary components they don't want distributed). If it matters at all, I am not sure if internally things are arranged as a Unix command-line tool or an app bundle.--Ken