If you look at all these steps needed, I'm fairly sure a "normal" (i.e. ![]() dmg) with a "right click" and then acknowledge installing from an unsigned installation package - something Apple warns you not to do. The problem is even worse than barefootguru described: Because the language packs are not signed, you have open the language pack (the one within the. I beg to differ as a really long time StarOffice/OOo/LO user - and MAC user since 3 years: An application should be self-contained and not rely on data outside the app bundle. 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. Applications/LibreOffice.app: a sealed resource is missing or invalidįile added: /Applications/LibreOffice.app/Contents/Resources/autotext/sv/crdbus50.bauįile added: /Applications/LibreOffice.app/Contents/Resources/autotext/sv/standard.bauĪpproach 2 puts data in directories that are not apparent to the user. $ codesign -v -v /Applications/LibreOffice.app 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: 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?). In my opinion there are some real problems with approach 1 and 2:Īpproach 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. Every langpack installer would need to include signatures for all of those combinations which include the installed language. a quick calculation gives me more than 13000 possible combinations of language packs. 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. Deliver updated code signatures as part of the language pack. 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:Ĥ. Because the installer of the langpack already is a program, it should be possible to get the necessary admin rights to do this.Ģ.1 Langpack install script checks also for depecated langpacks with no fitting LO installation (similar to the way it finds it's right install version) and deletes them. Therefor put a symlink into the package which directs to the appropriate directory in systems Library/Application Support folder. change the location of the langpack from LO-package to systems library. Perhaps this could be done always so no check is necessary.Ģ. or LO is started by the langpack-install script and killed immediately after that so gatekeeper has had it's chance. a warning dialog is given in language of the langpack that LO has to run one time to install a langpack.ġ.2. when installing a langpack, the installer checks if a first run of LO has taken place (is that possible?). There is also a rights problem with the lang-pack install, see separate bug report: īesides fixing I see two possible workarounds:ġ. Since most non-English users automatically install lang-pack over a new LO installation without first running the install, it means that most non-English users will run into this problem. Modified LO installation, and allows to open LO (at least on 10.10.2)." Installed into it, it appears that Gatekeeper does not re-verify the If the installed LO had already been started before the language pack is You should move it to the Trash." error and Installed into it, trying to open LO leads to a "'LibreOffice' isĭamaged and can't be opened. If the installed LO had never been started before the language pack is ![]() ![]() LO installation, which is not endorsed at least by the updated (>= "For another, our language pack mechanism copies files into an existing I am pasting its most important part for this bug report regarding OS X lang-pack installation mechanism: mailing list sub-thread starting at "Re: OS X build signature"
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |