<html>
<head>
<base href="https://bugs.documentfoundation.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - The lang-pack installation mechanism on OSX unacceptable"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=89657#c12">Comment # 12</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - The lang-pack installation mechanism on OSX unacceptable"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=89657">bug 89657</a>
from <span class="vcard"><a class="email" href="mailto:catacombae@gmail.com" title="catacombae@gmail.com">catacombae@gmail.com</a>
</span></b>
<pre>[OS X developer and long time LibreOffice user, first time LibreOffice Bugzilla
commenter...]
I would prefer approach 3 as suggested by barefootguru, but if that would grow
the size of the download to the point where it's unacceptable I would like to
add one other possibility:
4. Deliver updated code signatures as part of the language pack. However if the
user installs multiple language packs this might be a complicated issue where
the langpack installer must keep track of signatures for all possible
combinations of language packs... a quick calculation gives me more than 13000
possible combinations of language packs. Every langpack installer would need to
include signatures for all of those combinations which include the installed
language. Doable, but complicated.
In my opinion there are some real problems with approach 1 and 2:
Approach 1 relies on the fact that Gatekeeper will not check an app after it
has been checked the first time, so if we add content to the app bundle after
it has been verified the first time Gatekeeper doesn't care, but this sounds
more like a bug in Gatekeeper. If Gatekeeper should provide any level of
security it should detect modifications in a bundle after it has been checked
the first time (what if some malware did the modification?).
Indeed when checking the app with codesign after adding a language pack (in
this case the Swedish language pack) reveals that it's in fact not valid
anymore:
$ codesign -v -v /Applications/LibreOffice.app
/Applications/LibreOffice.app: a sealed resource is missing or invalid
file added:
/Applications/LibreOffice.app/Contents/Resources/autotext/sv/crdbus50.bau
file added:
/Applications/LibreOffice.app/Contents/Resources/autotext/sv/standard.bau
...
Approach 2 puts data in directories that are not apparent to the user. If the
user wants to uninstall LibreOffice the most obvious thing to do is to delete
the app, but that leaves unreferenced data behind in /Library, wasting disk
space. An application should be self-contained and not rely on data outside the
app bundle.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>