Post not yet marked as solved
yup, understood. thanks.I'll also add info to the bug report. the zip file is valid, but includes some unnecessary PK tags for the directory entries. the resulting zip file is valid, but clearly throws a wrench into some extraction tool used by the notarization service.
Post not yet marked as solved
Thanks for looking into this. I'll update the bug with info as you suggest. Thanks again!
Post not yet marked as solved
Bug submitted: FB7395461From that bug report:I've narrowed the problem down to a small test zip archive (we are notarizing pkgs, but I thought the zip test would be a simpler demonstration of the problem). The zip contains a folder with a simple .app, and a zip archive that contains a few JavaScript source files and a few .json files. If I just put the app in a zip it notarizes fine -- it's only there so the zip is considered "valid" by the notarization service. Also, if I expand the internal zip and just include the files directly in the container zip, notarization works.
Post not yet marked as solved
This is the one that's a few days old: 786837c6-e9af-4732-aa42-49973acedadaHere's the more recent one: f9444a87-f3c8-4e15-882f-da558c547623Thanks
Post not yet marked as solved
Here's the source for a simple tool that adds the RSA signature: https://gist.github.com/kurash/57e18d6e6e98f397f42086194b7b67bdThe command for compiling is at the top of the file. Usage is like: pkgresign mypackage.pkg
Post not yet marked as solved
Thanks for the clarification on stapling the pkgs. As for the dmg:If your users download the disk image, mount it, copy off the installer package, and then open the package on the same machine that mounted the disk image, notarising just the disk image will be fine. If the workflow is more complex, can you elaborate on what that is?We provide a dmg so there is just one file to download. The dmg contains installers for our server, admin tool, client, etc. So typically our customers will download the dmg and copy the installers to be used/distributed individually to various computers. The dmg also contains installers for Windows, LInux, etc. So the dmg is just a convenient container for those of our customers who prefer Macs. We also build a zip file with the exact same contents so customers who prefer other platforms can get all of our software in a single download. Also too, we provide each installer as a separate download for those who just need one component or another instead of all the things.
Post not yet marked as solved
I'm a bit late to the party, but I think the problem is that newer versions of packagesign put the RSA signature into the pkg, it only puts the CMS sig in place. Older versions of OSX only know to check the RSA signature.It is possible to add the RSA sig yourself, there's nothing magical about packagesign.Quinn (or anyone at Apple) if you are interested, see radar 47434137, which is now FB5386538 (?) As I wrote in that bug report, I have code that demonstrates the issue if that is needed. I still have that code sitting on my desktop.
Post not yet marked as solved
I ran into this same issue, although in my case the app is already not using ARC. I added the following to the "Other Liinker Flags" setting: -Xlinker -U -Xlinker _objc_loadClassrefI'm not sure this is a proper fix, but at least it gets the link to succeed and does not seem to cause any issues during run time. I'm using this just so I can get some work done, not necessarily as a final fix. I fear that leaving this in place might break the app on older OSs.Anyway, maybe this can get you back to a working build, at least until someone from Apple gives you a better answer...
Post not yet marked as solved
After further research, I have come to the conclusion that productsign is not properly signing pkg files. The CMS signature is correct, but the RSA signature is not. Furthermore, I believe that the installer does not really care about the RSA signature, and only checks (I hope!) the CMS signature. Certainly pkgutil --check-signature does not complain about the incorrect RSA sig.Our code checks both, so I've added a step to our build process that places the correct RSA signature in our pkg files after we first run productsign to get the CMS sig in place.radar 47434137
Post not yet marked as solved
That might have been the starting point, although I think the docs were a bit different a few years ago. It must be, as you say, that security was tightened since then, since our app group value does not use the team prefix mentioned in the (newer?) docs. Adding the prefix would defeat the purpose (of our use of this entitlement). If we just needed to allow IPC between our own apps, we'd use XPC services and be done with it.
Post not yet marked as solved
I'll see if I can find the source of information.I'm fine with using com.apple.security.temporary-exception.mach-lookup.global-name. The only thing that puts me off from it is the "temporary" part.Thanks!
Post not yet marked as solved
This has worked for a few years now (at least since Dec 20 2016, when the commit to our svn happened). I did it this way based on some docs from Apple, or maybe on some guidance from DTS (?) I can't recall where the information originated. It's also remotely possible I just looked at darwin source to figure out what would work, but I don't think darwin source has sandboxing in it, soi that seems unlikely.Is there a non-temporary entitlement that can be used for this, and that will work in the case of a Hardened app? Or some other mechinsm that will allow third-party apps to communicate with our system daemon?
Post not yet marked as solved
In my .entitlements file (also appears in the Xcode GUI) I've got:<key>com.apple.security.application-groups</key>
<array>
<string>com.company.moof</string>
</array>Our deamon calls bootstrap_check_in(..., "com.company.moof.random-stuff", ...) when creating the port, and clients use bootstrap_look_up to set up the connection with the appropriate port name. Works a charm until I enable Hardening in the client app.
