Comment 10 for bug 1857377

No there is no deeper issue, run spctl on the top level bundle and it
will work fine. And its made that way precisely because of the
combination of sandboxing and the way bundles work in apple land. This
problem absolutely does not exist with chroot.

ebook-viewer and ebook-edit need to be sub-bundles with their own
Info.plist so that they can be used independently and also so that they
show correct icons in the dock. Bundles + codesigning require their own
individual executables. That is why there are executables named, for
example: ebook-viewer-placeholder-for-codesigning

However the bundles cannot duplicate webengine since that would blow up
their size. Which means there can be only one real copy of WebEngine, in
the outermost bundle, with symlinks in inner bundles. And the Webengine
sandbox restricts itself to the bundle the current executable
is running from, determined by argv[0] of all the stupid things.
Which means it needs to be inside the ebook-edit bundle
that is inside the ebook-viewer bundle that is inside the calibre
bundle. So that it can be used from calibre, ebook-viewer and

This architecture is totally ridiculous. And no I am not happy about it.
Bundles, code signing and the absolute joke that is notarization, are
all clearly inferior technologies that force insane contortions on
application developers, for zero real benefit. All this crap is badly
designed, horribly documented and changes from macOS release to macOS
release. I wasted two weeks of my life because of it. Just look at the
code in the calibre source tree for creating these bundles, signing and
notarizing them, piles and piles of un-dcumented black magic, ugh.

And that is not even to mention the ridiculous bugs in macOS, like