-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
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
Add MEGAsync by mega.co.nz #5338
Conversation
Please don't merge yet. Seems like app won't start unless installed in /Applications. Any ideas? Thanks. |
Fixed by linking directly to /Applications. |
This is an unusual solution, and could cause unexpected results (to users, not technically). Do you know why the software has this limitation? We had a similar case some time ago (trying to remember what cask it was), that also needed to be installed to |
Main binary contains the following: Seems like this applications requires suid to operate and has hardcoded path to it's binary. |
I think it is |
It is. Thank you. Apparently we still have no definitive answer on how it went. The caveat is a solution I’m fine with, though. @eugenesan Does MEGAsync ask to be moved to |
@vitorgalvao MEGAsync silently refuses to start from any other location. |
Failing silently is really a crappy experience, even if we add a caveat. It would likely be less confusing (to users) to just outright move the whole app bundle into I somewhat doubt they really need the app in |
I have just fired a question to their support, I will keep you posted here if they reply. |
Fri, Jul 18, 2014 at 1:44 AM BST:
|
Greetings from the MEGA team. There are two reasons that led us to use absolute paths to executables in /Applications/MEGAsync. MEGAsync fails to start in other locations because the little loader also uses an absolute path to start the main binary. We could get the path of the current executable and start the other one from the same folder but that would require to do it at runtime using a system framework or an external library. That would add complexity to this loader and would make it an easier target for malicious attacks that could try to exploit it to gain root access. Anyway, we are open to any suggestions to improve this, keeping the security as the main priority. |
Thank you @javiserrano, for taking the time to come here and clarifying your reasonings (and thank you @radeksimko for contacting support). As stated, failing silently is the real issue, especially since you don’t really need the app bundle itself to be in That, to me, sounds like the easiest solution. Instead of failing silently, ask to move the app to where you need it, and nothing else needs to change. There are other apps that do something similar (although in those cases, it’s usually more of a suggestion, and not mandatory). |
I fully agree with you @vitorgalvao. MEGAsync should ask to move the app to /Applications or at least should show an error message. I will explain why we don't immediately improve this: The current version starts running the loader as root, the loader opens /dev/fsevents and finally it launches MEGAsync (the MEGAclient binary) without admin privileges using a hardcoded path. In order to improve this, we would have to change the loader and, when users update to the new version, they would have to enter their root password again to restore the setuid bit. We are currently working on Finder integration to show overlay icons and context menus for files/folders. Those changes will also require to change the loader and thus to request the root password. As these improvements will be probably ready in a couple of months, we think that it's better to wait a bit and to put all improvements regarding the root loader in that update to not ask for the root password twice (many users don't like to type his root password and we prefer to avoid it if it isn't absolutely necessary). During this time, I think that we will also improve the update feature to be able to update the loader without asking for the root password. That way we won't have these problems again. |
Switching to full variant since light variant is not available.
This is a follow-up to Homebrew#5338. I had no issues installing and running the MEGAsync client using this caskfile.
A better solution from upstream would still be preferred, but in the meantime #8804 adds a caveat for this. |
No description provided.