Post not yet marked as solved
Ok, thanks for the reply.
So as far as the installers go, localization is pretty much restricted to a few readme / license text files, and the system decides the rest based on the user's currently selected language in system preferences. It also seems like it might be tricky to determine the user's language in a postinstall script since the installer runs as root.
Post not yet marked as solved
Hi Gary,
I've encountered a similar problem, which I made a separate thread about here:
https://developer.apple.com/forums/thread/702907
Were you ever able to solve your problem?
Post not yet marked as solved
Ok, I will take your suggestion and open a DTS.
At this point it seems like the question is at least in part easy to define: Should a privileged Helper be able to access a removable volume? Is the answer yes, or no?
Does it work for other people? Try making a privileged helper according to EBAS and see if it can, say, access a file on a removable volume (or, the Downloads or Documents folder).
Now with further testing here, the app CAN access removable volumes the first time it's run when the helper is installed, AND in my current testing it is also working the SECOND time (??). If I then close the app and run it again, a THIRD time, then it no longer works. There is no way at all to make it work after this, with the exception of manually unloading and uninstalling the daemon and helper.
I don't understand this. How can I develop an app that will stop working for the user with no way to fix it?
Post not yet marked as solved
Further to my last reply, I tried to work-around this by simply copying the installer package from the removable disk prior to running it. And...
I've now discovered an 'even worse' problem, which is that the installation does not work ("install failed. Authorization is required to install the packages.") if the install -target is a removable disk. The symptoms are the same, it works only the very first time the privileged helper is installed and does not work again after that.
For anyone else reading this, note that the title of this thread is misleading, because I mistakenly thought it could be fixed by manually checking the box in Full Disk Access.
Is there any way to give the PrivilegedHelper access to removable volumes? If not, is there any different strategy I can use to run an installer package from my app? (aside from just opening the package in the GUI installer.app)
For context, this is a download and installation manager, that is used to install many different packages, some quite large (plugins, additional content, etc..) for our main program.
Post not yet marked as solved
Thanks for the VM suggestion - I will research that. In the mean time I tested it on a "fresh" clone of a Catalina drive I happen to have.
I’m confused by what you mean by “app” in this context.
What I meant by this specifically is the helper tool, which the app calls via XPC. I guess my thinking was that the helper tool would automatically be inheriting the TCC privilege.
I did as you suggested and added code to the app itself to access the file on the removable disk. Indeed, the first time I run the app, a dialog asks me for permission to access removable disks (which it didn't before, and I can see the app has been successfully added to the Security 'Files and Folders' area) and it copies/renames the file successfully. However the helper tool still fails to run the file using installer.
On the fresh Catalina disk, I get the exact same behavior. The helper tool can access and install the package successfully unless it's on a removable drive (or in Downloads folder etc.). So this issue does not seem to be specific to the development machine.
Because if that’s not working you have bigger problems
Gulp...
Post not yet marked as solved
Thanks for the response. I made another discovery. The app CAN actually access the Downloads folder. But ONLY the first time it's run when the helper is installed. Then, it doesn't work again unless I launchctl unload and load.
Also, I realize there is a bigger problem. Let me expand a bit on this, the download location is user selectable, since the installer packages may be quite large and users like to download them to an external volume. This is an important feature for our app, and unfortunately external volumes suffer from the same problem as the Downloads folder.
(1) Is this expected behavior?
(2) Is there any way around this?
Thanks.
Post not yet marked as solved
The feedback report number is FB8788850
Post not yet marked as solved
In the error 73 case, was the package built and signed on 10.13? Or 10.14? There was no difference which OS was used to build/sign.
We did upgrade the machine to OS 10.14 and stapling works now. Xcode 10 is still installed.
Apple should perhaps update the requirements on this page:
https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution
"Stapling an app requires macOS 10.12 or later."
Post not yet marked as solved
With regards the stapling issue, how are you building myInstaller.pkg? With an Apple tool? Which one? pkgbuild was used to compile the pkg, and then it was signed by productsign. So to summarize where I stand:
All steps including notarization are successful on both OS 10.13 and 10.14.
Stapler fails on OS 10.13 with the error 73 message I reported in a previous message.
I don't see any relevancy. You are talking about doing development on operating systems that are 2 and 3 major versions behind. Don't do that. Well my question WAS specifically about an older OS. At this point, I'm still not sure if stapler is compatible with 10.13. It seems like people expect it to work, but have not tried it.
We can likely upgrade the machine to 10.14, I will find out and report back with my findings.
Post not yet marked as solved
To add something that may be relevant after further testing...
On another dev computer that our team has (with Mojave), stapler does work.
When I type the following command for myInstaller.pkg (which HAS been successfully notarized) , I get a slightly different result on each machine.
spctl -a -t install -vvvv myInstaller.pkg
On the 10.13 machine:
myInstaller.pkg: accepted
source=Developer ID
origin=Developer ID Installer: myCompany
On the 10.14 machine:
myInstaller.pkg: accepted
source=Notarized Developer ID
origin=Developer ID Installer: myCompany
Post not yet marked as solved
Thank you. I have updated to OS 10.13.6 now. XCode 10 now works, and I can successfully notarize an installer package.
However, I now have a problem stapling. (I have tried recompling and notarizing several times with same result)
When I enter this command after notarizing:
xcrun stapler staple -v "myInstaller.pkg"
I get this:
...
...
...
Downloaded ticket has been stored at file:///var/folders/pd/rf2jcjzj0g1f3hw04l19r1fcsq1r5/T/b65b63be-30e8-4ff6-986f-02682df537bc.ticket.
Attempting to attach a new ticket to myInstaller.pkg. Let’s see how that works out.
Processing: myInstaller.pkg
Properties are {
NSURLIsDirectoryKey = 0;
NSURLIsPackageKey = 0;
NSURLIsSymbolicLinkKey = 0;
NSURLLocalizedTypeDescriptionKey = “Installer package”;
NSURLTypeIdentifierKey = “com.apple.installer-package-archive”;
“NSURLIsApplicationKey” = 0;
}
We do not know how to deal with trailer version 65055. Exepected 1
Although we wrote the ticket, the written data did not validate. Please restore myInstaller.pkg from backup to try again.
The staple and validate action failed! Error 73.
Post not yet marked as solved
Ok... On this page:
https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution
"Notarization requires Xcode 10 or later. Building a new app for notarization requires macOS 10.13.6 or later. Stapling an app requires macOS 10.12 or later."
This would seem to be saying that notarization is possible on 10.12, or maybe it can literally only be stapled on 10.12 but not notarized (not sure if that makes sense).
Anyhow, I have an installer package that has been signed (on OS 10.12.6) and I would like to notarize it now (on OS 10.12.6). I am wondering if this is possible, if so presumably there is a command line tool set or Xcode version that I can download from my developer account. Hence my question.
Post not yet marked as solved
I have submitted a TS ticket. To answer a previous question: Yes, it is OS 10.6.8, with the latest updates installed.
Post not yet marked as solved
I'm observing the exactly the same error as the OP. I will add that the certificate has not changed as far as I know. I just updated from Sierra to Mojave. Additionally I tried using the productsign binary from my Sierra installation, and had the same result.Is it possible to sign a package on Mojave, that is compatible with 10.6?
