maestral
maestral copied to clipboard
Use sandboxing for the macOS app bundle
This would allow distribution over the App Store and the automatic updates that come with it (see #316). It would also have security benefits.
Possible road blocks from a first trial:
- Terminal I/O for the command line interface is not working because it requires access to STDIN which is apparently not available for a sanboxed app. Not even launching an interactive Python prompt works from a sandboxed app (though running Python scripts without I/O works just fine). There ought to be a solution for this but it will require some research.
- At the moment, the daemon and GUI are both using the same executable which is launched with different command line flags. This is no longer possible for a sandboxed app where subprocesses must run a separate helper which inherits its entitlements from the parent executable. This means that we would need to split the app into two executables and ideally dynamically link to the Python framework instead of static linking to keep the executable size small. This means upstream work in briefcase which is used for packaging or switching to having a full Xcode project in the first place.
- We would need to redesign the GUI to explicitly ask for a Dropbox folder location on first launch instead of offering a default. This is because file system access must be granted explicitly by a user through an "Open" dialog. The granted access needs to be somehow passed on to the daemon process.
- We need to use security scoped bookmarks to remember file system permissions between launches.