I have some concerns about this, especially the hibernatemode 25 undo command. On my MacBook Pro (Retina, 15-inch, Mid 2015) running macOS Mojave version 10.14.4 with Turn display off after: set to 1 hr, pmset -g returns. App Cleaner & Uninstaller finds all types of startup programs on Mac and allows you to easily disable or enable them. Follow this link to download the app for free. Run App Cleaner & Uninstaller. Go to the Startup Programs section. Select unneeded apps and switch their toggle buttons or click the Disable button.
Starting in macOS 10.12, you can no longer provide external code or data alongside your code-signed app in a zip archive or unsigned disk image. An app distributed outside the Mac App Store runs from a randomized path when it is launched and so cannot access such external resources. To provide secure execution, code sign your disk image itself using the codesign tool, or distribute your app through the Mac App Store. For more information, see the updated revision to macOS Code Signing In Depth.This is further explained in the equally misnamed “OS X Code Signing In Depth“: If using a disk image to ship an app, users should drag the app from the image to its desired installation location (usually /Applications) before launching it. This also applies to apps installed via ZIP or other archive formats or apps downloaded to the Downloads directory: ask the user to drag the app to /Applications and launch it from there. This practice avoids an attack where a validly signed app launched from a disk image, ZIP archive, or ISO (CD/DVD) image can load malicious code or content from untrusted locations on the same image or archive. Starting with macOS Sierra, running a newly-downloaded app from a disk image, archive, or the Downloads directory will cause Gatekeeper to isolate that app at a unspecified read-only location in the filesystem. This will prevent the app from accessing code or content using relative paths.The gist is, if an app isn’t signed via the Mac App Store, Gatekeeper is going to limit the ability of the app to launch via “Gatekeeper Path Randomization.” Basically, treat an app from a mounted drive as if it were coming from a Safari download. There are a few ways to distribute app bundles or binaries that do not violate this. One is to sign a disk image that contains such an app: spctl -a -t open --context context:primary-signature -v /Volumes/MyApp/MyApp.dmg If spctl runs properly, you should see the following:
/Volumes/MyApp/MyAppImage.dmg: accepted source=mydeveloperid Mac Disable App Translocation SoftwareIn the above spctl command, we use the following options:
![]() xattr -r -d com.apple.quarantine /Volumes/MyApp/MyAppImage.app The options in the above use of the xattr command:
xattr dump on a given file, use the -l option as follows: xattr -l com.apple.quarantine MyAppImage.dmg The output is as follows:
xattr: No such file: com.apple.quarantine MyAppImage.dmg: com.apple.metadata:kMDItemDownloadedDate: 00000000 62 70 6C 69 73 74 30 30 A1 01 33 41 BE 31 0B A5 |bplist00.3A.1.| 00000010 70 D4 56 08 0A 00 00 00 00 00 00 01 01 00 00 00 |p.V………….| 00000020 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 |…………….| 00000030 00 00 00 00 13 |….| 00000035 MyAppImage.dmg: com.apple.metadata:kMDItemWhereFroms: 00000000 62 70 6C 69 73 74 30 30 A1 01 5F 10 22 63 69 64 |bplist00._.”cid| 00000010 3A 69 6D 61 67 65 30 30 31 2E 70 6E 67 40 30 31 |:myappimage.dmg@01| 00000020 44 32 36 46 46 44 2E 35 37 31 30 37 30 46 30 08 |D26FFD.571070F0.| 00000030 0A 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 |…………….| 00000040 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….| 00000050 2F |/| 00000051This could be helpful when troubleshooting and/or scripting (or just way too much informations!). Finally, if you’re an application developer, check out new API for App Translocation in the 10.12 SDK for <Security/SecTranslocate.h> I guess one way to think of this is… Apple doesn’t want you running software this way any more. And traditionally they lock things down further, not less, so probably best to find alternatives to running apps out of images, from a strategy standpoint.
ProgrammingNotarizing Disk Images for Developer ID Distribution
Distributing macOS apps within
.zip files nowadays is no longer a good idea. One issue is app translocation. Another issue is the mandatory notarization starting from macOS 10.15 Catalina.
App translocation goes into effect when the user downloads a
.zip file containing an application, extracts it, and runs it directly without moving it anywhere using the Finder. The operating system would run your app from a temporary read-only disk image created just for the purpose of launching your app. This has an unfortunate side effect of Sparkle being unable to update your app – which prevents you from delivering updates and bug fixes seamlessly to your user.
Notarization is the method to register your software packages to Apple when you distribute outside the App Store. The problem with packaging software inside a
.zip file comes from the inability to attach the notarization result on to the archive. Therefore your user’s system would need to be online to check whether your software package has been notarized. Otherwise it would prompt a “macOS can not validate…” warning to the user, possibly causing suspicion to your package. However when the notarization result is stapled to your package, macOS can validate it without making a network connection to Apple.
Thus disk images is probably the best way to distribute application bundles outside the Mac App Store. Disk images can be signed, notarized, and stapled. When you distribute apps using disk images and Sparkle, your users would find it straightforwardly effortless to install, use, and update.
But creating disk images is an involved task for the developer. There are so many tasks involved to package an application into a disk image ready for the user. This includes:
That’s a lot of steps to do manually on each release. Thankfully all of those steps can be automated and added to your continuous integration environment. Hence you can automatically get a finished disk image on every release. Even if you don’t have a build server, integrating this to your Xcode build would be a snap. Read on to learn how to do this.
Prerequisites
Before you begin, make sure that you have these at hand:
Creating the Disk Image
The
create-dmg command would cover steps 1–5 of the disk image creation process. It would create a disk image out of your application bundle, add a symbolic link to the /Applications folder as well as adding a background image when the disk image is shown in a Finder window.
The following is a sample command-line invocation of
create-dmg . It packages YourAppName.app that is located in StagingDir into disk image AppPackage.dmg . A staging folder is required since create-dmg would copy everything Pause screenshot app on mac. inside it to the resulting disk image.
For more information on each parameter, you can look into
create-dmg ’s built-in documentation:
External ringer for digital phone. Note that the disk image’s background image need to be matched up with parameters to
create-dmg which positions icons in the disk image. I’ve provided a generic background image that is already “aligned” with the above command.
Should this generic background is not sufficient, you can use my Affinity Designer template to create your own background. Download the template file from project DiskImageDistribution. in my Github account.
create-dmg would create an almost-ready disk image. However you would need to sign and notarize this disk image before distributing it.
Signing the Disk Image
Run the following command to sign a disk image using your Developer ID account. You shouldn’t notarize the disk image without signing it first — although the notarization process may give it a pass, Catalina’s Gatekeeper won’t trust it if the application bundle inside it was signed on 1 June 2019 or later.
Notarizing the Disk Image
The following command would upload the disk image to Apple for notarization. It is an asynchronous process which usually takes a minute or two. When successfully uploaded, the command would return a UUID that you can use to check the notarization process. However a successful upload does not necessarily mean successful notarization.
You could use the following command to check the notarization process, armed with the UUID returned upon upload.
You could invoke the above command repeatedly to see whether the notarization process is completed, or wait for an e-mail from Apple telling you that it is done.
Mac Disable App Translocation App
When the notarization process is completed, the command would provide a URL to the notarization log in the
LogURL field returned. Connected apps on apple tv mac. Hence if something went wrong, you could fetch that URL and see what was the issue.
Stapling the Notarization Result
Notarization would keep a copy of your package in Apple’s servers and create an identifier based on its hash. When Gatekeeper would need to check whether a package is notarized, it would derive its hash and use it to contact Apple’s servers to find out whether it was notarized. If Gatekeeper can’t connect to the Internet, it would simply refuse to open the package.
To prevent this from happening, you would need to embed the notarization result into your package. This process is called stapling – which is to staple the “certificate of notarization” that Apple provides on to your disk image. With the notarization result stapled, Gatekeeper would not need to go online to check for it – thus allowing your users to open your package as per normal.
Use the following command to staple the notarization certificate on to the disk image.
The above command can also be used to poll for notarization result. When the command’s exit status value is
65 , it means that the notarization process isn’t yet completed. Hence you can just call this command repeatedly in a continuous integration environment to wait for the notarization process, which usually takes less than a minute.
An example would be like so:
Verifying the Resulting Disk Image
When you’ve completed everything, verify the resulting disk image using the following command:
When it returns with a “Notarized Developer ID” then the package is ready and valid for notarization.
Putting it All Together
I’ve written a shell script that you can use as a starting point to integrate notarization into your build pipeline. You can also invoke this script as a custom build phase in Xcode.
Download the script from my Github project: DiskImageDistribution.
Next Steps
Integrate notarization into your continuous integration pipeline. You don’t need to sign and notarize every build – just the ones that you are going to distribute, including beta versions. Is there a mac app for spotify.
Leave a ReplyComments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |