← Back to team overview

kicad-developers team mailing list archive

Re: macos notarization status

 

Adam (et al.),

If you didn't have to package the single top executable (e.g. eeschema,
pcbnew) would this allow you to remove the symlinks? We have been
discussing adding command line flags to the main kicad executable to launch
the various frames as standalone (e.g. `kicad --eeschema` would launch a
standalone eeschema instance instead of the manager frame), so then we
wouldn't have to actually have the single top executables for those anymore.

Would that fix your issue?

Thanks,
-Ian

On Mon, Feb 3, 2020 at 2:12 PM Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>
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
> > <stegmaier@xxxxxxxxxxxxx> 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
> >> <adamwolf@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References