-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gatekeeper Path Randomization makes life hard #182
Comments
@keithduncan krona for your thoughts. |
Some other discussions about this: potionfactory/LetsMove#56 |
I've confirmed that removing
It sucks that it means they won't get updates on the first run, but... that's not too bad compared to the current behavior. |
Assuming #183 is misguided... I'm struggling to come up with any other ideas. We could try to detect when path randomization is being applied and just not check for updates? |
Just found this thread while googling for something else related. We documented the issue for Sparkle at: sparkle-project/Sparkle#832 https://sparkle-project.org/documentation/ In short, we do nothing special, other than disabling updates if the app is running from a read-only mount, which needs to be handled anyway if the app is running inside a dmg. Apple wants developers to ship code signed dmg's now to avoid translocation and not zips. Maybe not ideal, but we'd rather not oppose them by writing a hack to clear a quarantine bit. App developers could use something like LetsMove if they want, but we don't handle that kind of logic ourselves. |
Thanks @zorgiepoo!
I think you're right that this is the best path forward 👍 |
#186 addressed this as best as I know how for now. |
Because of MacOS Gatekeeper path randomization issues (Squirrel/Squirrel.Mac#182) we need the user to move the app themselves. Changed the dialog to ask them to do this politely.
Because of MacOS Gatekeeper path randomization issues (Squirrel/Squirrel.Mac#182) we need the user to move the app themselves. Changed the dialog to ask them to do this politely. Conflicts: internal_packages/verify-install-location/lib/main.es6
Use staging autoupdater for staging. fixed failing test Fix autoupdater – we were using the wrong command. Revert "Bump version to 1.5.0" Temporarily reverting this because I need to test the upgrade path from 0.4.2 => 1.5.0 Revert "Revert "Bump version to 1.5.0"" Had to do this to test the autoupdater. [fix] [channel drop-down list] Show the stable channel in all cases. Conflicts: internal_packages/preferences/lib/tabs/update-channel-section.jsx Fix broken autoupdater, for reals. [master] Replace "Nylas N1" by "Nylas Mail" in build scripts Summary: As discussed --- we need to make those changes to make the autoupdater work across versions. Test Plan: Will run a build. Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D3701 Revert "Revert "Revert "Bump version to 1.5.0""" Need to set the version to 0.4.402 for testing purposes. Set preferredChannel in the autoupdater instead of in the ChannelStore It turns out that Squirrel checks for update at program launch. In some cases, it would put Pro users on the "nylas-mail" channel because that's the default channel if you don't pass a preferredChannel. Conflicts: src/flux/stores/update-channel-store.es6 Set the autoupdater preferredChannel to stable. Don't try to move the app file to the Application folder ourselves Because of MacOS Gatekeeper path randomization issues (Squirrel/Squirrel.Mac#182) we need the user to move the app themselves. Changed the dialog to ask them to do this politely. Conflicts: internal_packages/verify-install-location/lib/main.es6
Use staging autoupdater for staging. fixed failing test Fix autoupdater – we were using the wrong command. Revert "Bump version to 1.5.0" Temporarily reverting this because I need to test the upgrade path from 0.4.2 => 1.5.0 Revert "Revert "Bump version to 1.5.0"" Had to do this to test the autoupdater. [fix] [channel drop-down list] Show the stable channel in all cases. Conflicts: internal_packages/preferences/lib/tabs/update-channel-section.jsx Fix broken autoupdater, for reals. [master] Replace "Nylas N1" by "Nylas Mail" in build scripts Summary: As discussed --- we need to make those changes to make the autoupdater work across versions. Test Plan: Will run a build. Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D3701 Revert "Revert "Revert "Bump version to 1.5.0""" Need to set the version to 0.4.402 for testing purposes. Set preferredChannel in the autoupdater instead of in the ChannelStore It turns out that Squirrel checks for update at program launch. In some cases, it would put Pro users on the "nylas-mail" channel because that's the default channel if you don't pass a preferredChannel. Conflicts: src/flux/stores/update-channel-store.es6 Set the autoupdater preferredChannel to stable. Don't try to move the app file to the Application folder ourselves Because of MacOS Gatekeeper path randomization issues (Squirrel/Squirrel.Mac#182) we need the user to move the app themselves. Changed the dialog to ask them to do this politely. Conflicts: internal_packages/verify-install-location/lib/main.es6
I am directed to this issue when I try to update Atom. I am not running Atom from a read-only location, nor is it in my Downloads folder. It is in a subfolder of my Dropbox, located in my user directory. And yet, I receive the error message that follows:
|
@repertor I had the same issue and also not running from a read-only volume but i just did what the first post here said:
I moved it out of my applications folder and back again and the updater worked fine. (I guess I moved the Atom.app into the applications folder with Alfred.app instead of just moving it in Finder) |
Thanks, @himynameisjonas. I had unzipped Atom directly into the directory from the download, so moving it in and out solved the problem. |
@himynameisjonas @repertor -- I tried
but it had no effect. Is there some trick about how you move? |
I just dragged it to the desktop and back in the Finder.
…--
Jonas Brusman
On 28 aug. 2017 20:33 +0200, Shaun Cutts ***@***.***>, wrote:
@himynameisjonas @repertor -- I tried
$ mv /Applications/Atom.app ~
$ mv ~/Atop.app /Applications
but it had no effect. Is there some trick about how you move?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@shaunc You may need to move it using the Finder for it to work. |
FYI - I'm new to mac platform, but the update only started working when I restarted my mac after the move from Downloads to Applications via Finder. Not sure whether it's normal or not but it might save someone a bit of trouble... |
For anyone arriving here, here's what solved the problem for me:
|
That wfm. Specifically
|
Hello! |
Thanks @himynameisjonas
|
Running OXS 10.14.5. Had the atom installed in Moving it to the desktop and back via Finder did not work. Permissions looked right via cli.
|
I had to make sure I opened it outside of downloads. I even had to re-install it and then move it to applications and THEN open it there. Weird. |
That's working as expected for app translocation (i.e, you need to move the app using Finder to have auto-updates available). Atom needs to update Squirrel so it doesn't try to auto-update in that scenario and/or ship their app in a signed/notarized dmg. That's an issue for Atom, not here. |
Actually I take that back.. Looking at the code it looks like squirrel tries to notify the user if an update is available. It shouldn't. It should silently fail unless the user manually requests for an update like Sparkle. Responsibility is left to the apps or other frameworks (eg LetsMove) if they want the app to not be on a read-only volume. To each their own. |
This is happening when the Atom.app resides in ~/Applications |
Verified: using Iterm2 to mv ~/Downloads/Atom.app to /Applications keeps the read-only error. Using Finder to drag and drop it to /Applications allows the updater to function. macOS Mojave Version 10.14.6 |
Yep, same here.
Worked fine after that. Hope that helps. |
~/Downloads
.This is because of Gatekeeper's path randomization, new in Sierra. Once you do something that deactivates path randomization (e.g., move the app), updates are fine.
This sucks. It's not terribly clear how we can deal with it. Try to detect it and tell users? Maybe we can explicitly de-quarantine the running app from ShipIt?
The text was updated successfully, but these errors were encountered: