Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index


Am 15.06.20 um 11:33 schrieb Tor Lillqvist:
(Sorry, my fingers slipped somehow and my previous reply had no of my
own text.)

    4) create a real macOS installer package (native macOS installer
    program, not a runnable script like the langauge pack "installer"),
    similar to the windows msi that allows to customize the installation
    and pick the components you want.


But where would such a "real" installer install the optional parts? Into
the app bundle? Is it possible to leave out optional parts from a signed
and notarized app bundle, if done by an installer? I honestly don't
know. But my guess would be no, that leaving things out from the signed
app bundle is no different from adding files to it later (as the
language packs now do).

Sure, such an installer could instead put the optional parts in for
instance /Library or ~/Library. But then we are back at the problem I
already wasted a couple of weeks on: Teaching the LO code in various
places to look up various things (message catalogs, extensions,
autotexts, dictionaries, help, whatnot) in multiple locations. Which
seems quite hard. At least to me, but somebody else who understands the
code better might do it in a day, of course.

Maybe that complicated, multi-directory lookup is not needed. Quoting
from "Technical Note TN2206 - macOS Code Signing In Depth"[1]:

= Changes That Don't Invalidate a Code Signature =

There are a few changes you can make to a signed bundle that won't
invalidate its signature.

If you have optional or replaceable content you wish to change without
invalidating the code signature, nested code can be replaced with
equivalent (conforms to the designated requirement) nested code without
disturbing the outer signature. This is the design mechanism for
indirection in code bundles. It is acceptable to code-sign a bundle
containing no main executable, and then treat it as nested code
(typically in Contents).

Removing files from .lproj directories inside Contents/Resources will
not invalidate the code signature, but adding or changing files will.

-----------------

So if I understand this correctly, then maybe we can pre-register all
the language pack content in the main "installer" / app and in the end
the language pack "installers" would work like re-adding files to the
"Contents/Resources"?

[1]
https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG402

P.S. I neither have a Mac nor any possibility to verify this
interpretation. I was just searching for "apple macos code signing
optional parts" and this came up.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.