Skip to content
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

Slow performance under OSX Catalina #327

Open
craigraw opened this issue May 6, 2020 · 4 comments
Open

Slow performance under OSX Catalina #327

craigraw opened this issue May 6, 2020 · 4 comments
Labels

Comments

@craigraw
Copy link

craigraw commented May 6, 2020

OS Catalina has introduced stricter security on running binaries, which has dramatically affected the performance of the hwi binaries. Because of the way the binaries are packaged, the full security check (including a remote network call) is made upon every invocation.

The issue is specifically related to the use of PyInstaller, and is described here. In brief, every invocation of hwi expands the python runtime and associated files to a temporary folder, where it is considered by OSX to be a new executable requiring a security check. This security check fails unless it is specifically permitted in System Preferences, but even once this has been done the security check runs every time hwi is executed. On my system this takes around 5 secs.

One workaround to reduce the time taken is to set api.apple-cloudkit.com to point to localhost in /etc/hosts - the security check still runs but at least takes less time.

I have also managed to build a version of hwi that is a folder rather than a binary with PyInstaller using --onedir, as suggested in the link above. This means that at least subsequent executions are instant, even if this is more unwieldy. It doesn't solve the security failure on the first run however for new users.

Ultimately I think the right solution is to codesign and notarize the executables as per Apple's requirements, but I'm not sure if there are better ideas?

@achow101
Copy link
Member

achow101 commented May 6, 2020

I'm hesitant to make macOS specific changes as I have no way to test them (I don't have a mac). I'd like to avoid making onedir builds as they are very unwieldy and harder to distribute. For new users, using a onedir build may not be easy to understand.

Ultimately I think the right solution is to codesign and notarize the executables as per Apple's requirements

IIRC in Core there was some concerns about privacy as doing so results in macOS phoning home to look up the notarization even if it's attached to the binary. Also, I'd need a mac to do this.

@craigraw
Copy link
Author

craigraw commented May 7, 2020

I'd like to avoid making onedir builds as they are very unwieldy and harder to distribute. For new users, using a onedir build may not be easy to understand.

I agree, although having a 5-10 sec delay on every invocation is pretty unwieldy too :(

IIRC in Core there was some concerns about privacy as doing so results in macOS phoning home to look up the notarization even if it's attached to the binary.

I assume you're referring to this issue: bitcoin/bitcoin#15774
Stapling the notarization ticket seems to remove the need for the online check, although I haven't been able to confirm it won't happen for certain.

Also, I'd need a mac to do this.

I have a mac, but I'm not very familiar with Python packaging options - and of course the signing process relies on the developer's certificate. Perhaps this all needs to be done remotely as proposed in the issue mentioned above. Either way it doesn't appear to be possible to target OSX as platform going forward without some kind of plan, unfortunately. I'm fairly confident the solution is relatively simple for simple command line binaries and .app packages - for binaries that expand themselves to temporary folders, I'm less sure.

@craigraw
Copy link
Author

craigraw commented May 9, 2020

FWIW I have tested a distribution approach that satisfies Apple's requirements. Specifically, I have:

  1. Built a --onedir PyInstaller distribution
  2. Code signed all of the the files in it
  3. Built a .pkg installer of these files and code signed the .pkg
  4. Submitted the .pkg to Apple for notarization
  5. Received successful notarization
  6. Stapled the notarization ticket to the .pkg
  7. Successfully tested with spctl --assess -vvv --type install hwi-1.1.0.pkg
  8. Uploaded and downloaded the .pkg (to add the com.apple.quarantine xattribute to the file)
  9. Installed the .pkg on OSX 10.15.4

The installation proceeded normally and no disabling of Gatekeeper in OSX System Preferences was required. However, the initial online security check still happened on the first ./hwi invocation, which is troubling. It's not done on subsequent invocations though.

If I delete the installation and repeat the install without being online, the first invocation of ./hwi is immediate, so I assume the stapled ticket is used.

Hopefully these notes may be useful.

@NicolasDorier
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants