Big Sur interfering with KiCAD (solved)

Software
1

macOS Big Sur 11.5, KiCAD version 5.1.0-0-10_14

I had occasion to look up something in EESchema for the first time since upgrading Big Sur to 11.5, and macOS says I’m not permitted to open EESchema directly??

I had to launch the project file, THEN launch EESchema from there, an extra step I’m not used to.

Did something break in the 11.5 upgrade or is this the workflow that is coming up in version 6?

2

This is probably the wrong question. You may better ask what new workflow is enforced by Apple after each update.

I had the same issue. I could solve the problem by doing
SUDO xattr -d com.apple.quarantine /Applications/KiCad/kicad.app/Contents/Applications/eeschema.app
in the terminal, as described in https://stackoverflow.com/questions/64842819/cant-run-app-because-of-permission-in-big-sur/64895860#64895860

4 Likes
3

Excellent! That worked. Thank you!

4

This is still a problem. I believe the underlying issue is related to Gatekeeper. For instance, if you view the extended attributes for the applications (using xattr in terminal) the com.apple.quarantine attribute is set for kicad.app, eeschema.app and pcbnew.app. When you inspect the app to determine if it has been signed, the apps have not been code signed.

I think the reason kicad.app runs is because it has been added to the Privacy pane in the Security and Privacy files and folders settings. I believe this creates a Gatekeeper exception for kicad.app which allows it to run. However, eeschema.app and pcbnew.app are not included in the list. I am not sure why kicad.app gets added to this pane but eeschema.app and pcbnew.app are not.

So, removing the com.apple.quarantine attribute described above works around the problem by removing the item from quarantine. But, that is not actually addressing the underlying security vulnerability. I am not a Gatekeeper expert but I think if the applications were signed we would not encounter this issue. Is there any plan to sign the apps?

5

The nightly builds are signed and notarized (as will be the 6.0 release). We have no plans to go back and start notarizing 5.1 at this time (it’s a lot of effort to set up, and the two branches are pretty different at this point)

7

Thank you for the update. FYI, I ran into an issue with one of the nightly builds (I think it was 12060). When I checked the code signing it appeared to me this built was not signed. I had a problem with this build crashing so I downloaded an earlier build (12032). It has been signed.

8

Those numbers don’t mean anything to me, the easiest way to ID a nightly build is the git commit hash (a build date is OK but imperfect). But, that doesn’t surprise me:

  • It took us a long time to get the notarization thing working
  • After it started working initially, there was at least one period where it had to be disabled for a bit

By the way, as far as I know the builds have been signed for a long time. The issue is notarization, which is an additional step involving sending the built files to Apple.

9

Yeah, I should have included the hash.

Thank you for the feedback.

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.