OK, I see… this is weird. My understanding from what I read in the documentation was, that it should sign everything in the top-level bundle (kicad.app) including sub-apps you might have in kicad.app/Contents/Applications.
Regards, Bernhard > On 3. Feb 2020, at 16:47, Adam Wolf <adamw...@feelslikeburning.com> wrote: > > I am not notarizing the DMGs. While this is possible, it has not been > necessary so far. > > When I tried notarizing kicad.app but not the others, when I move to a > new computer, it complains that eeschema.app is not notarized. > > The problem is not putting the signed kicad.app into an unsigned dmg. > > On Mon, Feb 3, 2020 at 8:11 AM Bernhard Stegmaier > <stegma...@sw-systems.de> wrote: >> >> Hi Adam, >> >> I am also no fan of the symlinks, but having a different approach will >> be probably some work. >> >>> I had someone ask if what we do would work during WWDC and I was told >>> it would not work. I consistently get "the signature is invalid" when >>> signing while we have symlinks, and when I remove the symlinks and >>> just sign KiCad.app this error goes away. >> >> I don't doubt that the symlinks in the DMG don't work. >> What you explained is exactly what I had in mind: >> (1) Sign *only* kicad.app as is. No complete DMG with symlinks or >> whatever. >> (2) Create DMG with previously signed kicad.app and symlinks, libraries >> and whatever you put into. Don't try to notarize this DMG, DMG is just >> a container. >> >> Doesn't that work? >> kicad.app is signed and the DMG should just acts as some kind of zip >> file then... ? >> >> If the problem is putting the signed kicad.app into a (unsigned) DMG, >> maybe just distributing via .zip would be also a viable way meanwhile? >> Many other applications also do this... >> >> >> Regards, >> Bernhard >> >> Am 3.2.2020 14:46, schrieb Adam Wolf: >>> Bernhard, >>> >>> I have no personal vendetta against the symlinks. >>> >>> I had someone ask if what we do would work during WWDC and I was told >>> it would not work. I consistently get "the signature is invalid" when >>> signing while we have symlinks, and when I remove the symlinks and >>> just sign KiCad.app this error goes away. >>> >>> I am not sure if Apple gives themselves special entitlements that mere >>> mortals don't get. I'm not sure if I'm just not able to get it to >>> work. >>> >>> Nothing I have done so far relies on the symlinks going away, so if >>> you think you can make it work, please let me know. >>> >>> My personal suggestion for working around the symlinks issue was not >>> to just copy things, but rather just have a single KiCad.app that >>> would open itself in different ways of given a different type of file, >>> but others on the bug tracker preferred trying to copy things first. >>> >>> Frankly, it's exhausting spending all this time on things that users >>> don't see, when there are so many interesting fun things we could be >>> working on instead. >>> >>> In terms of what I am signing and notarizing, I have tried signing and >>> notarizing the app, the dmg, all the apps, basically every >>> combination. Apple's rules are extremely fickle here, and you could >>> even notarize unsigned things. They explicitly say the rules about >>> what you can notarize are hidden from developers! >>> >>> Adam >>> >>> On Mon, Feb 3, 2020, 1:08 AM Bernhard Stegmaier >>> <stegma...@sw-systems.de> wrote: >>> >>>> Hi Adam, >>>> >>>> I still don’t get it: >>>>> Our current >>>>> strategy of symlinking into the kicad.app bundle does not work >>>> with >>>>> macOS signing. >>>> >>>> Xcode has e.g. Instruments application in >>>> Xcode.app/Contents/Applications/Instruments.app >>>> If I symlink it (for example) to >>>> /Applications/Instruments.app >>>> It runs without any complaints when started via the symlink. >>>> >>>> What do you notarize? >>>> The overall dmg with the symlink? >>>> Have you already tried to only notarize kicad.app (no dmg, no >>>> symlinks) and put it into the dmg with symlinks afterwards? >>>> Another quick fix could be some script that can be run to create the >>>> symlinks on user machine? >>>> >>>> A simple copy of the apps won’t work. >>>> You need to change everything wrt shared libraries in KiCad code and >>>> cmake script. >>>> >>>> In the end, you will duplicate all libraries and support stuff. >>>> Probably not a big deal for eeschema and the other small apps, but I >>>> guess for pcbnew. >>>> Means duplicating all the python, nags-ice, etc. stuff. >>>> And also, all stuff like templates, scripts, etc. >>>> Users shouldn’t fiddle around in the .app, but could get really >>>> messy if they now put (template, python, spice?) stuff in kicad.app >>>> or pcbnew.app and then something doesn’t work in one or the >>>> other... >>>> >>>> Regards, >>>> Bernhard >>>> >>>>> On 3. Feb 2020, at 02:00, Adam Wolf >>>> <adamw...@feelslikeburning.com> wrote: >>>>> >>>>> Hi folks! >>>>> >>>>> Apple is changing how the lack of notarization looks like to users >>>> on >>>>> Catalina starting tomorrow. It is not clear what will happen when >>>>> folks download new versions of KiCad after tonight. >>>>> >>>>> For the past two months I've been working hard--I've got a tech >>>> demo >>>>> locally here that has signatures and notarization on macOS, but >>>> it's >>>>> not ready for primetime. For instance, I have removed the other >>>> .apps >>>>> and just have kicad.app. There's changes I made to kicad that >>>>> probably belong in kicad-mac-builder--and, well, let's just say >>>> it's a >>>>> tech demo :) >>>>> >>>>> The main things that remain are: >>>>> 1) Figure out a good solution for the symlinked .apps. Our >>>> current >>>>> strategy of symlinking into the kicad.app bundle does not work >>>> with >>>>> macOS signing. I think the current contender is to copy instead >>>> of >>>>> symlink. I am not sure how much extra space that will take up but >>>>> it's a good try. This is definitely something I can do, but since >>>>> it's something that can be done on its own, it's a prime contender >>>> for >>>>> someone looking to help out. >>>>> >>>>> 2) Another issue is that there are strict rules about where in the >>>>> bundle code, data, and executable non-Mach-O files live. For >>>>> instance, one of the signing blockers is ngspice, because it >>>> mingles >>>>> scripts and Mach-O binaries and then we put them in >>>> Contents/Plugins. >>>>> For more details, see >>>>> >>>> >>> https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG201. >>>>> The big change for KiCad itself is where the Python scripts are >>>>> stored--I've fixed this in my branch, but now I have to go through >>>> and >>>>> audit and fixup our partner packages, like OCE/OCC and ngspice. >>>> If >>>>> you want to help with this, it's going to be a big job but I'm >>>> willing >>>>> to put in the time to teach if you're willing to put in the time >>>> to >>>>> learn :) >>>>> >>>>> I was really hoping I could get this done before Apple turned up >>>> the >>>>> enforcement on notarization, but that's going to happen. After >>>>> tomorrow, it'll be clearer what Apple is doing. There might be >>>> some >>>>> quick changes to make that will improve things for our users >>>> without >>>>> getting all of this done. >>>>> >>>>> Adam Wolf >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : kicad-developers@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
