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

Closed
joshaber opened this Issue Sep 29, 2016 · 19 comments

Comments

Projects
None yet
@joshaber
Copy link
Contributor

joshaber commented Sep 29, 2016

  1. Use macOS Sierra.
  2. Download an app to ~/Downloads.
  3. Launch app.
  4. Update found.
  5. Prompted to auth update helper (??)
  6. Update can't be installed.

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?

@joshaber

This comment has been minimized.

Copy link
Contributor

joshaber commented Sep 29, 2016

@keithduncan krona for your thoughts.

@joshaber

This comment has been minimized.

Copy link
Contributor

joshaber commented Sep 29, 2016

@joshaber

This comment has been minimized.

Copy link
Contributor

joshaber commented Sep 29, 2016

I've confirmed that removing com.apple.quarantine from the app fixes this. So what if we did this:

  1. Check for updates.
  2. Notice the host app still has com.apple.quarantine.
  3. Clear the bit.
  4. Since the app was launched with com.apple.quarantine, we can't update it until it's relaunch, so don't check for updates.

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.

@joshaber

This comment has been minimized.

Copy link
Contributor

joshaber commented Oct 6, 2016

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?

@zorgiepoo

This comment has been minimized.

Copy link

zorgiepoo commented Oct 9, 2016

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.

@joshaber

This comment has been minimized.

Copy link
Contributor

joshaber commented Oct 10, 2016

Thanks @zorgiepoo!

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.

I think you're right that this is the best path forward 👍

@joshaber

This comment has been minimized.

Copy link
Contributor

joshaber commented Oct 18, 2016

#186 addressed this as best as I know how for now.

@joshaber joshaber closed this Oct 18, 2016

khamidou added a commit to nylas/nylas-mail that referenced this issue Jan 16, 2017

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.

khamidou added a commit to nylas/nylas-mail that referenced this issue Jan 16, 2017

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

emorikawa added a commit to nylas/nylas-mail that referenced this issue Jan 16, 2017

Remove UpdateChannelSection
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

emorikawa added a commit to nylas/nylas-mail that referenced this issue Jan 17, 2017

Remove UpdateChannelSection
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
@repertor

This comment has been minimized.

Copy link

repertor commented Jul 26, 2017

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:

Cannot update while running on a read-only volume. The application is on a read-only volume. Please move the application and try again. If you're on macOS Sierra or later, you'll need to move the application out of the Downloads directory. See #182 for more information.

@himynameisjonas

This comment has been minimized.

Copy link

himynameisjonas commented Jul 26, 2017

@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:

Once you do something that deactivates path randomization (e.g., move the app), updates are fine.

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)

@repertor

This comment has been minimized.

Copy link

repertor commented Jul 26, 2017

Thanks, @himynameisjonas. I had unzipped Atom directly into the directory from the download, so moving it in and out solved the problem.

@shaunc

This comment has been minimized.

Copy link

shaunc commented Aug 28, 2017

@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?

@himynameisjonas

This comment has been minimized.

Copy link

himynameisjonas commented Aug 28, 2017

@joshaber

This comment has been minimized.

Copy link
Contributor

joshaber commented Aug 31, 2017

@shaunc You may need to move it using the Finder for it to work.

tierninho added a commit to desktop/desktop that referenced this issue Sep 12, 2017

@albertbuchard

This comment has been minimized.

Copy link

albertbuchard commented Jan 10, 2018

sudo chown -R $(whoami):admin /Applications/Atom.app/

@avner-hoffmann

This comment has been minimized.

Copy link

avner-hoffmann commented May 24, 2018

Hi, what was the decision about this issue?
To do nothing?

@armstrong360 armstrong360 referenced this issue Jun 13, 2018

Closed

Signal Dock Icon #2438

1 of 1 task complete
@caioalmeida97

This comment has been minimized.

Copy link

caioalmeida97 commented Jul 18, 2018

Hello

I tried dragging the Atom.app from the Applications folder into the Desktop (just like @himynameisjonas said), but it just creates a new Atom.app alias, and when i drag the Atom.app alias back to the Applications folder, nothing happens.

Any ideas of what to do?

@weshicks

This comment has been minimized.

Copy link

weshicks commented Jul 22, 2018

@caioalmeida97 CMD + drag to the desktop so that it doesn't create shortcut. I was having this problem with VS Code and this solved it for me. (Make sure the app isn't running just to be safe.)

@merriam

This comment has been minimized.

Copy link

merriam commented Sep 27, 2018

Please do note:

  1. The issue is "closed". It was not "resolved". The shortest answer is "sometimes goes away; live with it."
  2. New users run into this on their first exposure to Atom. That is, the first impression is "OK, Atom only works sometimes".
@mrmass

This comment has been minimized.

Copy link

mrmass commented Dec 5, 2018

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment