search

Squirrel / Squirrel.Mac

:shipit: Cocoa framework for updating OS X apps :shipit:
MIT License
1.59k stars 128 forks source link

Gatekeeper Path Randomization makes life hard #182

Closed joshaber closed 8 years ago

joshaber commented 8 years ago
  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 commented 8 years ago

@keithduncan krona for your thoughts.

joshaber commented 8 years ago

Some other discussions about this:

https://github.com/potionfactory/LetsMove/issues/56 http://www.openradar.me/radar?id=5022734169931776

joshaber commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

Just found this thread while googling for something else related. We documented the issue for Sparkle at: https://github.com/sparkle-project/Sparkle/issues/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 commented 8 years ago

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 commented 8 years ago

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

repertor commented 7 years ago

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 https://github.com/Squirrel/Squirrel.Mac/issues/182 for more information.

himynameisjonas commented 7 years ago

@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 commented 7 years ago

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

shaunc commented 7 years ago

@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 commented 7 years ago

I just dragged it to the desktop and back in the Finder.

-- Jonas Brusman

On 28 aug. 2017 20:33 +0200, Shaun Cutts notifications@github.com, 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.

joshaber commented 7 years ago

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

albertbuchard commented 6 years ago

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

avner-hoffmann commented 6 years ago

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

caioalmeida97 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 5 years ago

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

hassenius commented 5 years ago

For anyone arriving here, here's what solved the problem for me:

  1. Shutdown Atom
  2. Run (in a terminal) 
    mv ~/Downloads/Atom.app ~/Applications/
xattr -dr com.apple.quarantine ~/Applications/Atom.app
  3. Start Atom again It was now able to run updates no problem
aberezin commented 5 years ago

That wfm. Specifically

  1. shutdown Atom
  2. cd /path/to/my/apps/
  3. xattr -dr com.apple.quarantine ./Atom.app
lukasz-formela commented 5 years ago

Hello! As @mrmass stated: Not only you have to move the app but you also need to restart the platform. Kudos!

m-lamarre commented 5 years ago

I moved it out of my applications folder and back again and the updater worked fine.

Thanks @himynameisjonas This worked for me. My Atom was in the Applications folder. So I moved it to the Desktop and back, and now Updates are downloading 😅 🤷‍♀ 🤦‍♀ 

cmd + c 'Atom'
alt + cmd + v to move it to a new location
willthemoor commented 5 years ago

Running OXS 10.14.5. Had the atom installed in /Applications.

Moving it to the desktop and back via Finder did not work. Permissions looked right via cli.

xattr -dr com.apple.quarantine /Applications/Atom.app/ and xattr -dr com.apple.quarantine /Applications/Atom\ Beta.app/ worked for me.

brando90 commented 5 years ago

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.

zorgiepoo commented 5 years ago

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.

zorgiepoo commented 5 years ago

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.

danwetherald commented 5 years ago

This is happening when the Atom.app resides in ~/Applications

jhriv commented 4 years ago

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

MichaelRDionne commented 2 years ago

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.

Yep, same here.

  1. I quit VSC
  2. moved the APP from downloads to Applications
  3. opened VSC from inside the Applications folder.

Worked fine after that. Hope that helps.