Hi Ivan, thanks for looking into this. On Mon, Mar 18, 2019 at 06:25:53PM -0700, Ivan Andrus wrote: > I haven't worked on Sage for quite a while, but it was brought to my > attention (thanks Karl-Dieter), that the Mac application no longer works on > Mojave. I believe this has to do with the fact that the application isn't > signed by a registered developer. I say this because starting it from the > command line (e.g. $ /Applications/SageMath-8.5.app/Contents/MacOS/Sage) > starts > up instantly and, as near as I can tell, perfectly. However, when I double > click in the Finder, it gets stuck (for a very long time--maybe 10 minutes) > in _LSResolveAllQuarantineItems(...) in [NSWorkspace > openFile:withApplication:andDeactivate:]. Ten minutes may not be forever, > but it's certainly longer than we should require people to wait, especially > given that it's every time they launch the app. This explains that weird delays people mentioned which using the app, another "clever" OSX joke...
> I can think of a few options that might be able to solve the problem: > > 1. We could start signing the code. However, I don't think signing it > will be possible since one of the first things that happens when running > sage is that it changes the paths embedded in certain executables (at > least > that's what I remember). Changing anything in the application (code or > resources [1]) would invalidate the signing, so I think that's out. it's a technological problem here: as LD_LIBRARY_PATH using was no longer possible on OSX (and it's a hassle anyway), Volker's https://github.com/sagemath/binary-pkg builds a distribution with paths being templates, that are replaced with actual paths once the installation is known. What would be the correct way to achieve this on OSX? Simply assume that Sage must be installed in /Applications/SageMath and build the distibution with the whole absolute paths known in advance -- surely this could be signed then, no? Or there is something more clever? > 2. We may be able to replace our use of [NSWorkspace > openFile:withApplication:andDeactivate:] with something else, perhaps > using > system(). I haven't tried this, so I have no idea if it will work. > 3. We could move to a two-item approach in which we provide the app > *without* sage embedded inside it (so it's very small and could be > signed, or not), and then we provide the sage distribution separately > (could be in the same dmg file, just not embedded). For a long time, the > application has had the ability to use to any sage installation. However, > it might be difficult to automatically point people to the latest > installation (i.e. they would have to go into the app preferences and > change it themselves). We could offer some sort of installer that would > copy the sage distribution and make that change for the current user. > Perhaps sysadmins could just create a symlink to the latest or something. > I'm not sure what problems we've seen people have in this area. Also, > you > would probably lose the ability to run multiple versions of the app to > quickly switch back and forth. > 4. Create an AppleScript (or Terminal) launcher that just runs a > variation of the script below [2] rather than starting the app directly. > This seems to work fine, but is somewhat annoying to need a different > launcher. This can hopefully work as a stop-gap for those who have this > problem right now. > > In my opinion #3 is the most promising. How bad is #3 from a user > experience perspective? I used to always run it that way, so it's not a > problem for me, but I've been out of the loop for a while, and my > experience might not be typical. What problems do people foresee with > integrating any of these with the build system? Right now I'm not able to > build sage. I haven't dug into why, but I can if need be. Unfortunately, > I don't know how much time I'll be able to devote to working on this so any > help would be appreciated. Another still not completely resolved, issue is openssl. The current Python.org' Python OSX installer papers over it in a laughable (IMHO) way: https://bugs.python.org/issue36344 (TLDR: they package fully functional pip, with all certs etc. as well as openssl, broken by not having cert.pem in the right place, and "fix" this by calling a special script that calls pip to install cert.pem into the right place, even though this cert is already there in the installer, in pip, to be precise!) Perhaps it's meant to satisfy a (not very smart) lawyer, I don't know... If you have ideas about the latter, it would be good, too. Best, Dima > > Please keep me in CC, since I'm no longer subscribed to sage-devel. > > -Ivan > > [1] > https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html#//apple_ref/doc/uid/TP40005929-CH4-SW5 > > [2]* do shell script* "/Applications/SageMath-8.5.app/Contents/MacOS/Sage > >/dev/null 2>/dev/null&" > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
