Hacker News Reader

Comment by zZorgz | Hacker News Reader

The main concern is that software updaters will not be able to easily replace an app bundle if it is translocated to a readonly mount. The user will have to move the app somewhere else first.

Apple wants developers to use dmgs (and signed ones particularly) but updaters don't have an easy time with apps being launched from those either, and people don't think dmgs provide a good user experience as well.

View on HN

Software updaters need to handle the case of the app being on read-only media anyway. If your app breaks because it was launched from read-only media, that's absolutely a problem with the app and not a problem with the system.

Perhaps, but it's unlikely that many do. Updating such an app would involve writing the new update to a different location, which could pose a challenge for not confusing the user. The Mac App Store doesn't have to deal with this.

Some developers that distribute their app in dmg's try to nudge the user to move the application for them into /Applications, but that's kind of hostile, and developers shouldn't have to go out of their way to do that.

Before 10.12 at least, developers were generally okay with the updater not running on read-only media - this is more intended behavior rather than being 'broken'.

Anyway, just pointing out the real concern from the article.

In the case of a software updater, I think "not updating" is probably correct behavior. Broken behavior would be the app crashing or misbehaving or throwing errors because it tries to update the app on read-only media.

Not updating is what most apps currently do in this case.

The author's concern is that they (and many other developers) ship apps in zips, have many users download them, and run them from ~/Downloads/ or wherever their browser downloaded the app to. Only in 10.12, this practice will prevent most 3rd party apps from being able to update themselves.

The author wants an info.plist key (plus perhaps app signing) to opt-out of translocation and say that they are competent enough. Before thinking that this "defeats" the point, people may miss that Apple is fine with opting out provided you code sign and package a dmg.

The author and many others also don't like dmgs, however, and find that they confuse many users. What the author is concerned about does indeed affect a lot of apps.

I would expect that people who run an app from ~/Downloads are doing so because they don't know if they want to actually keep it and are just testing it out. Similarly, many apps already check if they're launched from a DMG or from ~/Downloads and ask the user if they want to move the app to the Applications folder, so that's a pretty simple fix for any self-updating app to adopt.

I don't want to be asked about moving apps somewhere else especially for testing them. It is kind of hostile. And it's a burden for the dev to include yet more code for this. IMO, Apple should have a way to solve the issue for out-of-store apps.

(I really don't know if that many apps do this btw, I think most apps I download today are packaged in zip..)

Other users are just baffled and run apps from disk images or Downloads just because.

The authors point is that at least before 10.12 zip was a decent approach.

Too bad they aren't offering signed zip or something similar that takes same advantages that a signed dmg does..

A signed zip is still dangerous. If the attacker can convince the user to download two files instead of just one, the attacker controls the names of the folders that contains the extracted zip contents (i.e. the name of the zip), so any app that looks at ../foo/bar would still be vulnerable.

The Info.plist approach (where the app declares that it has no such relative path dependencies and so should skip gatekeeper path randomization) seems like the best approach for fixing this "issue".

Reply on news.ycombinator.com