June 2016 - Installer-dev - lists.apple.com

About codesigned disk images
by Stephane Sudre 20 Jun '16

20 Jun '16

I'm a bit surprised that according to the public session: 1. this is said to be done via codesign(1) and not via hdiutil(1) as this is related to disk images. 2. since this is to be done via codesign, this means it will use the "Developer ID Application" certificate instead of the "Developer ID Installer" certificate used by the other distribution formats: .pkg and .xip files. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by Stephane Sudre 13 Jun '16

13 Jun '16

On Mon, Jun 13, 2016 at 8:53 PM, Erik Berglund <e.berglund(a)macsupport.se> wrote: > Yes, SMJobBless is the way to do it, it's used to install the helper tool and set it up for launchd. The example project I linked uses that. > > And, yes, If you're developing for the Apple platform you should use a developer certificate, which is just $99 a year. That's somehow inaccurate. The developer certificate is $99. As long as the Developer ID (Application|Installer) certificates are not about to expire, you don't have to renew your membership annually. You only have to renew your membership annually if you are shipping products on the (Mac) App Store. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by Erik Berglund 13 Jun '16

13 Jun '16

Yes, SMJobBless is the way to do it, it's used to install the helper tool and set it up for launchd. The example project I linked uses that. And, yes, If you're developing for the Apple platform you should use a developer certificate, which is just $99 a year. The installer tool will exit with a non-zero status, you can also use flags (-verboseR) to get the verbose installer output (logs) where (if any) the error information is printed. I agree it's not pretty as one would hope as it's a standalone binary, but if it fails it behaves as expected and exits with an exit code that might be helpful. I completely agree that it would be much more helpful to use a framework directly for this, but unfortunately that's not available and probably won't ever be available as they just point at the AppStore. So, just checking the exit status of the NSTask should be enough to know if it was successful or not, and to get error details you probably have to parse the output. This is done by many applications so there should be examples on GitHub on how others solved this. Sorry if you got some hard responses, but as you can guess, the Adobe way is not appreciated, and by that I mean to use for example a custom installer.app to move files into place instead of using the standard pkg format. But, as you've stated many times, if your just using pkgs, then the angry responses can be ignored. I use the privileged helper (SMJobBless) in some application and it's working great, some of them even calls /usr/sbin/installer. So, to my knowledge this is the appropriate way to do silent installations. But, if anyone else has input, feel free to add. > On 13 juni 2016, at 20:40, John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> wrote: > > On 06/13/2016 08:33 PM, Erik Berglund wrote: >> Using NSTask is the way to do this > > How do I verify the installation worked as expected? How do I read out the error message in case it fails? > >> but using AppleScript to elevate privileges is deprecated, you need to create a helper application that you call which >> handles the privilege escalation. >> > Which is incredibly convoluted when using SMJobBless. In fact, it requires the application to be signed with an Apple > Developer account. You can't even build Apple's sample app to test the mechanism. > >> If you just use standard pkgs, then all you need is the /usr/sbin/installer binary, that is silent and supported. > > Again, the problem is that there is no reliable way to query the installer. > >> As for elevating privileges, then you create a privileged helper tool that you use to run the installation task. >> >> https://developer.apple.com/library/mac/documentation/Security/Conceptual/S… >> https://developer.apple.com/library/mac/samplecode/EvenBetterAuthorizationS… > > As far as I know, Apple wants you to use this mechanism nowadays: > >> https://developer.apple.com/library/mac/samplecode/SMJobBless/Introduction/… > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz(a)debian.org > `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by John Paul Adrian Glaubitz 13 Jun '16

13 Jun '16

On 06/13/2016 08:33 PM, Erik Berglund wrote: > Using NSTask is the way to do this How do I verify the installation worked as expected? How do I read out the error message in case it fails? > but using AppleScript to elevate privileges is deprecated, you need to create a helper application that you call which > handles the privilege escalation. > Which is incredibly convoluted when using SMJobBless. In fact, it requires the application to be signed with an Apple Developer account. You can't even build Apple's sample app to test the mechanism. > If you just use standard pkgs, then all you need is the /usr/sbin/installer binary, that is silent and supported. Again, the problem is that there is no reliable way to query the installer. > As for elevating privileges, then you create a privileged helper tool that you use to run the installation task. > > https://developer.apple.com/library/mac/documentation/Security/Conceptual/S… > https://developer.apple.com/library/mac/samplecode/EvenBetterAuthorizationS… As far as I know, Apple wants you to use this mechanism nowadays: > https://developer.apple.com/library/mac/samplecode/SMJobBless/Introduction/… Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz(a)debian.org `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by Erik Berglund 13 Jun '16

13 Jun '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by John Paul Adrian Glaubitz 13 Jun '16

13 Jun '16

On 06/13/2016 08:02 PM, Greg Neagle wrote: >> I'm sorry, but that's what's required by the customer. Adobe uses it in their extremely >> popular Creative Suite, so it cannot be that particularly wrong. > > I, and most anyone who manages a large number of Macs, will disagree. The vast majority of Macintosh users doesn't work on managed Macs, they work on single-user machines. Otherwise Apple wouldn't have stopped selling their X-Serve line of products and they wouldn't have reduced down their server operating system into a Server.app. But as I have mentioned multiple times already, I do not want to circumvent any mechanisms by the operating system, I want to *use* them. I, our customer, just wants to be able to manage my apps on their own, without having to resort on Apple's AppStore which would mean that for every application sold, Apple gets a 30% share. But I guess this is going to be in circles. I have hoped to get some help with the development of Apple's installer, as the name of the mailing list suggest. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz(a)debian.org `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by John Paul Adrian Glaubitz 13 Jun '16

13 Jun '16

On 06/13/2016 08:03 PM, Erik Berglund wrote: > If you do, you must then rely on that the application you're installing is on the magnitude of Adobe's to have an entire open source community create > workarounds just to install your software in a managed fashion. Except that the API that Apple provides does *not* allow to install software in managed fashion. Microsoft's MSI API, on the other hand, does allow exactly that. Besides, as I have mentioned multiple times, I do not want to circumvent any install mechanisms provided by the operating system, I want to use them. That's the whole point of using an API. If I wanted to workaround Apple's API, I wouldn't use .pkg files. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz(a)debian.org `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by Erik Berglund 13 Jun '16

13 Jun '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by Greg Neagle 13 Jun '16

13 Jun '16

> On Jun 13, 2016, at 9:50 AM, John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> wrote: > > On 06/13/2016 06:48 PM, Greg Neagle wrote: >> `/usr/bin/open /path/to/your/app.pkg` or the equivalent NSWorkspace methods. This will open Installer.app, ready to install your package. > > That's a very bad way of doing it as there is no way of catching any errors. > >>> This mechanism works perfectly fine on Windows and there is a well-supported and >>> stable API for that. On OSX, the API is hidden and convoluted. >>> >>> I basically want to imitate what Adobe is doing with their apps manager [1]. >> >> Please don't. > > I'm sorry, but that's what's required by the customer. Adobe uses it in their extremely > popular Creative Suite, so it cannot be that particularly wrong. I, and most anyone who manages a large number of Macs, will disagree. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz(a)debian.org > `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Accessing PackageKit programmatically
by John Paul Adrian Glaubitz 13 Jun '16

13 Jun '16

Hi Julian! On 06/13/2016 06:48 PM, Julian Devlin wrote: > We use the following, when testing from a Makefile: > sudo installer -tgt / -pkg foo.pkg > > I don’t know how successful you might be in avoiding sudo… The problem is that /usr/sbin/installer cannot be run from Objective-C code without a very crude hack. You basically have to embed Apple Script into your Objective-C code to be able to gain administrative privileges [1]. On Windows, there is the MSI library which has been part of Windows since Windows 2000 and it provides a clean and canonical access to the installer system [2]. Applications like Google Chrome use it to install their package updates in silent mode. I'm a bit surprised that Apple doesn't provide similar mechanisms. Adrian > [1] http://stackoverflow.com/questions/6841937/authorizationexecutewithprivileg… > [2] https://msdn.microsoft.com/en-us/library/windows/desktop/Aa369426(v=vs.85).… -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz(a)debian.org `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0