Since installing OSX 10.9.5, all existing release LibreOffice builds fail Gatekeeper verification (i.e. won't run unless security is relaxed to "Allow apps downloaded from: Anywhere" in System Preferences – Security & Privacy) A version 2 signature seems to now be a hard requirement (e.g. for 4.3.2.2:) $ spctl -a -t exec -vv /Applications/LibreOffice.app/ /Applications/LibreOffice.app/: rejected source=obsolete resource envelope origin=Developer ID Application: The Document Foundation $ codesign -dvvv /Applications/LibreOffice.app/ Executable=/Applications/LibreOffice.app/Contents/MacOS/soffice Identifier=org.libreoffice.script.LibreOffice Format=bundle with Mach-O thin (x86_64) CodeDirectory v=20100 size=203 flags=0x0(none) hashes=3+3 location=embedded Hash type=sha1 size=20 CDHash=76025406daa78d5fdd8b54881363b1ec08e770b7 Signature size=8531 Authority=Developer ID Application: The Document Foundation Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=19 Sep 2014 02:43:48 Info.plist entries=18 TeamIdentifier=not set Sealed Resources version=1 rules=5 files=0 Internal requirements count=1 size=196
Can not confirm wth existing installations of LO 4242, or 4142. My Gatekeeper settings are MacAppStore and identified developers
When I first launch eac app, I have to open the Applications folder, RMB to open, then confirm - perhaps that is what you mean in effect ? But I only have to do this once.
Also works for me with 4312
An attempted launch after update from 4312 to 432 fails with "unidentified developer message" Confirming, but workaround still valid
*** Bug 84457 has been marked as a duplicate of this bug. ***
Given OP and Alex T's comments moving this over to bug 75025 as a mab4.3 item.
@Robinson, Cloph, *, This looks to need attention for the release engineering workflow for the OSX builds: https://developer.apple.com/library/prerelease/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205
So.... Apple introduced a v2 codesigning, that came with additional rules and restrictions wrt to the Libreoffice.app/ layout These changes were done on master, the future 4.4 but are not trivial and carry a real risk of causing hard failure, since we had to move the locations of some very basic component, and it is quite possible that in some obscure corner of the product something is making wrong assumption as to where these things are. So This kind of patch is not a good candidate for a .4 release of a stable branch. On the other hand.. the lack of v2 signature is annoying but fairly easily worked-around. and the annoyance is a 1-time issue per new install. (and no you do not need to set permanently the 'allow app downloaded from Anywhere' in gatekeeper, all that is needed is, the first time you run Libreoffice to lauch it with right-click on the icon and select Open... the confirm you want to open it, when gatekeeper whine about signature) So at this point we will let libreoffice-4-3 as is wrt to signature and the future version 4.4 will support v2 signature.
*** Bug 87546 has been marked as a duplicate of this bug. ***
*** Bug 87979 has been marked as a duplicate of this bug. ***
Um, I just downloaded LibreOffice 4.4 on 10.9.5 and it's still won't run because of GateKeeper. Running spctl returns: -> % spctl -av /Applications/LibreOffice.app /Applications/LibreOffice.app: rejected source=obsolete resource envelope
Sorry, I should have included the same output that #0 included: % spctl -a -t exec -vv /Applications/LibreOffice.app /Applications/LibreOffice.app: rejected source=obsolete resource envelope origin=Developer ID Application: The Document Foundation % codesign -dvvv /Applications/LibreOffice.app Executable=/Applications/LibreOffice.app/Contents/MacOS/soffice Identifier=org.libreoffice.script.LibreOffice Format=bundle with Mach-O thin (x86_64) CodeDirectory v=20200 size=218 flags=0x0(none) hashes=3+3 location=embedded Hash type=sha1 size=20 CDHash=88e109ade6e935f286f459dd065ae9d8b4904b01 Signature size=8531 Authority=Developer ID Application: The Document Foundation Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Jan 22, 2015, 5:58:26 PM Info.plist entries=18 TeamIdentifier=7P5S3ZLCN7 Sealed Resources version=2 rules=6 files=320 Internal requirements count=1 size=196
Um, not sure it is a signature issue. Just Gatekeeper paranoia. No problem with 10.10.2--just need to <Ctrl> + Open on first launch and accept the dialog -- Opening "LibreOffice" will always allow it to run on this Mac.
(In reply to V Stuart Foote from comment #13) > Um, not sure it is a signature issue. Just Gatekeeper paranoia. > > No problem with 10.10.2--just need to <Ctrl> + Open on first launch and > accept the dialog -- Opening "LibreOffice" will always allow it to run on > this Mac. <Ctrl> + Open plus confirming at the warning dialog that says "developer identity cannot be confirmed" worked to launch the app, but that still means that still should be a bug. Most OS X users will be unable to use LibreOffice because of this issue, I doubt that's the situation you want happening.
(In reply to Greg from comment #11) > Um, I just downloaded LibreOffice 4.4 on 10.9.5 and it's still won't run > because of GateKeeper. Here's my understanding of how LO builds are supposed to function under Gatekeeper: https://wiki.documentfoundation.org/OS_X/Gatekeeper#Installing_LibreOffice For 4.4.x and 4.5.x, Gatekeeper will need to be set to 'Identified Developers' or a lower security level for builds to pass its check. If the reality is different (on a permanent or semi-permanent basis), then we should update the wiki page, as the System Requirements page links to it as a reference.
A fix to the issue that "Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete" is supposed to have landed already. For instance, comparing 4.3.0.4 and 4.4.0.3, $ codesign -dvvv ~/Development/LibreOffice/Binaries/4.3.0.4/LibreOffice-4.3.0.4.app ... Sealed Resources version=1 rules=5 files=0 $ codesign -dvvv /Applications/LibreOffice.app/ ... Sealed Resources version=2 rules=6 files=320 (the latter claims Version 2) However, just as reported in comment 12, the overall Gatekeeper validation still fails, and LO 4.4.0.3 won't load in OSX 10.10 unless Gatekeeper is overridden, even if it is set to "Identified developers"
Most probably this is a result of the issue described in http://stackoverflow.com/questions/25760651/why-application-with-version-2-envelope-working-on-os-x-10-9-not-accepted-by-gat (the use of "--resource-rules" during signing) If so, this is more properly a 10.10 specific issue now.
(In reply to Matthew Francis from comment #17) > Most probably this is a result of the issue described in > > http://stackoverflow.com/questions/25760651/why-application-with-version-2- > envelope-working-on-os-x-10-9-not-accepted-by-gat > > (the use of "--resource-rules" during signing) > > If so, this is more properly a 10.10 specific issue now. Like I mentioned, it fails on 10.9.5...
This fails for me too on 10.9.5 with LibreOffice_4.4.0_MacOS_x86-64.dmg. Is there a way to help diagnosing this?
It is being worked on... http://cgit.freedesktop.org/libreoffice/core/commit/?id=615fae2f67028f3c5c51c70c77dbaa9b9f3856d6 reports of test parallel installs of master from either TB61 or TB49 would be helpful to the process. http://dev-builds.libreoffice.org/daily/master/MacOSX-10.10@61/ http://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/
ah, hadn't been aware there's a bug filed for this when I did the above fix; see also <http://lists.freedesktop.org/archives/libreoffice/2015-February/066332.html> "Re: OS X build signature"
I tried 4.4.1RC2 on OSX 10.10.2 and this seems to be unresolved. Besides the LangPack problem (I opened also https://bugs.documentfoundation.org/show_bug.cgi?id=89561) it seems that the only way not to make OSX drop the installed LO4.4.1(RC2) to Trash is to press "Cancel" as it asks you upon the first launch and then going to "System Preferences" - "Securty & Privacy", selecting "From Anywhere" on General tab, then relaunching LO, closing it, changing security setting to higher ones on the General tab. Then LO launches normally. But this procedure, for most OS X users, is totally unacceptable and will just drive them away from trying LO (or wonder what is wrong, if they used 4.3 or 4.4.0 before that). So I am reopening this and marking it as a blocker.
To ASSIGNED rather than NEW...(guess we dumped REOPENED on new BZ). Sorry this is not a BLOCKER. Previously known issues (just not correct yet) and functional <Ctrl>+Open one off work around, rather than lowering security settings suggested in comment 22.
(In reply to miles from comment #22) > I tried 4.4.1RC2 on OSX 10.10.2 and this seems to be unresolved. > > Besides the LangPack problem (I opened also > https://bugs.documentfoundation.org/show_bug.cgi?id=89561) it seems that the > only way not to make OSX drop the installed LO4.4.1(RC2) to Trash is to > press "Cancel" as it asks you upon the first launch and then going to > "System Preferences" - "Securty & Privacy", selecting "From Anywhere" on > General tab, then relaunching LO, closing it, changing security setting to > higher ones on the General tab. > Then LO launches normally. Cannot reproduce with <http://dev-builds.libreoffice.org/pre-releases/mac/x86_64/LibreOffice_4.4.1.2_MacOS_x86-64.dmg> on a fresh Mac OS X 10.10.2 install (with default "Allow apps downloaded from: Mac App Store and identified developers" setting). Trying to open LibreOffice.app shows the "Verifying 'LibreOffice'..." progress bar and then the "'LibreOffice' is an application downloaded from the Internet. Are you sure you want to open it?" dialog, as expected.
(In reply to Stephan Bergmann from comment #24) > Trying to open LibreOffice.app shows the "Verifying 'LibreOffice'..." > progress bar and then the "'LibreOffice' is an application downloaded from > the Internet. Are you sure you want to open it?" dialog, as expected. Likewise it works for me -- with the http://dev-builds.libreoffice.org/pre-releases/mac/x86_64/LibreOffice_4.4.1.2_MacOS_x86-64.dmg package On OS X 10.10.2 with Systems Preferences -> Security & Privacy -> General: "Allow apps downloaded from:" set to default "Mac App store and identified developers" Same message on initial launch, without needing to override with a <Ctrl> + Open, which means the signature IS being accepted.
should we close this as RESOLVED WORKSFORME?
(In reply to tommy27 from comment #26) > should we close this as RESOLVED WORKSFORME? We have not heard back from the reporter of comment 22 (where this bug was last reopened, so back to resolved per comment 24 and comment 25. Please re-open if the problem still persists.