macOS 10.15 "Catalina", now in Public Beta, requires apps to not only have a developer certificate signature, but to have that signature "notarized" by Apple. See https://developer.apple.com/news/?id=06032019i and https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution for more details.
While users may run LibreOffice on 10.15 by right-clicking the app icon and choosing "Open" (the classic way to bypass Gatekeeper in macOS), this is not immediately obvious, and the ominous alert Apple gives ("LibreOffice can’t be opened because Apple cannot check it for malicious software.") may scare some users off.
While it is true that this is a bug for a beta OS, macOS 10.15 is expected to arrive in "Fall 2019", which isn't too far away.
@Pete : thanks for flagging this. If it hasn't been raised already on the qa irc channel, I'll repost, and see if there's been any input from the dev channel
Apparently, 6.3 will use notarization when released, but 6.2 will not, so the onus is on people to migrate to 6.3.
EOL for 6.2.x is 30/11/2019.
You can get LibreOffice 126.96.36.199 for Mac here -> https://downloadarchive.documentfoundation.org/libreoffice/old/188.8.131.52/mac/x86_64/
I confirmed that 184.108.40.206 (from the link that Xisco Faulí provided) launches and runs fine. When is 6.3 scheduled for general availability?
(In reply to Pete K. from comment #4)
> I confirmed that 220.127.116.11 (from the link that Xisco Faulí provided) launches
> and runs fine. When is 6.3 scheduled for general availability?
LibreOffice 6.3 will be released as final in August, 2019. See https://wiki.documentfoundation.org/ReleasePlan/6.3
Just installed production 18.104.22.168 on MacOS Catalina 10.15 Beta (19A546d), and I can confirm that the issue still exists - maybe an issue with notarisation?
Note: the issue exists for both the main LO Suite as well as the UI language pack I needed (English GB) - in both cases I had to use the workaround "Open" to get things to start.
Created attachment 153934 [details]
Screenshot of LangPack error message
Sorry, brain wasn't engaged on the main LO install, but the message is pretty much identical for the Language Pack - hereby screenshot.
Hmm, the switch back to XCode 9 for the release of LO631 seems not to allow for proper notarization under Apple's new rules...
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Created attachment 154540 [details]
MacOS Catalina warning window
Alas, still present.
Platform tested on: MacOS Catalina 10.15 Beta (latest released build, 19A573a, about a week old).
DMG verifies OK, and installs fine. On startup, the integrity warning appears and the application only opens when forced with admin "Open".
I did note the line "checking whether to do code signing... no" in the accompanying build.txt file, though, maybe relevant?
This bug is still present in the public release of MacOS 10.15 Catalina.
Note that I get the same result if I right click on the app in /Application and select "open"
Possibly useful information:
Darwin MattBook 19.0.0 Darwin Kernel Version 19.0.0: Wed Sep 25 20:18:50 PDT 2019; root:xnu-6153.11.26~2/RELEASE_X86_64 x86_64
spctl -avvv /Applications/LibreOffice.app/
source=Notarized Developer ID
origin=Developer ID Application: The Document Foundation (7P5S3ZLCN7)
Pete, Fred, MattJ:
Did you install a language pack before launching LibreOffice first?
(In reply to Buovjaga from comment #12)
> Pete, Fred, MattJ:
> Did you install a language pack before launching LibreOffice first?
No I did not install a language pack before trying to launch LibreOffice.
What difference would that make?
I am summarising thoughts and ideas from our release engineer.
Re: langpack: Langpack installer installs additional files to the app directory and internally it triggers a launch and clause to trigger initial verification. So far Mac was happy when the app was verified once, then later additions to its contents were OK. The theory was that maybe there was a change in this and it broke notarisation, but apparently not.
This would be interesting to check: did macOS settings as to what are allowed sources change in Catalina? So far the default was to allow installation from appstore as well as identified Developers.
MattJ's spctl output shows that everything *should* be OK with notarisation: It is "accepted" and source is not just Developer ID; but *Notarised* Developer ID. So if mac still complains, then because they either changed what sources are allowed by default, or because they changed the signature check in the OS without also updating the tools used by developers to actually create and verify a signature, most notably Apple's notarisation server where you upload everything to. That showed no errors and no warnings.
The guess is that it is not notarisation at fault, but something else.
I just tested this and installing a language pack did not make any difference.
I had previously remove the LibreOffice that I could not start.
I downloaded 6.3.2 from the Libreoffice site
I downloaded the en GB language pack from the LibreOffice site. There is no separate en US language pack.
I installed LibreOffice, then Installed the language pack.
The installation of the language pack failed, with a similar message about MacOS not being able to verify that it was free of malware. I was then prompted for a administrator password. After giving the password I got a message stating that the language pack installation had succeeded.
It then tried to start LibreOffice with the same message as before.
Installing a language pack does not help.
Now Catalina has been released and number of reports in ask.libreoffice.org about this issue is increasing as Catalina gets installed.
That was kinda the point of raising it early by some of us who had the beta installed :)
There seems to be a conflict between the MacOS command line tools reporting an OK status and the reality, which will then naturally get in the way of resolving the issue.
Apologies if this is kicking in an open door.
Just installed version: 22.214.171.124 (Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c) on MacOS Catalina 10.15 Beta (build 19A582a).
LO tripped the usual alerts, so manually activated.
However, the UK Language pack installer now DOES work immediately, and did not trip any alerts other than the one of it being downloaded from the Internet.
(In reply to Fred from comment #17)
> There seems to be a conflict between the MacOS command line tools reporting
> an OK status and the reality, which will then naturally get in the way of
> resolving the issue.
It's really not straight forward. Right now this is the best I have found so far as it tells you what "invalid resources" it complains about:
codesign --verify --deep --verbose <the app>
Using the above command you'll find that after modifying the app (e.g. language pack installation) you won't get it to pass.
That appears to conflict with what I found.
1 - install LO. Fails to open, so forced with the ctrl-click "Open" option. Now works.
2 - start Langpack UK/GB. Starts without any problems, executes, exits.
3 - start LO. Starts without any problems, set to English UK, done.
I'm not sure what is validated by Apple, but a langpack mod doesn't seem to change the status. That said, I haven't tried installing the Langpack *without* first starting (and thus authorising) LO - I suspect that will fail because LO has not yet had a permission override to execute.
Slight caveat: this is from memory as I lack the time to test again right now, my apologies.
I updated with the "supplemental update" Apple provided today.
I downloaded and installed LibreOffice 6.3.2
I tried to start it by double clicking the icon and got the same dialog as previously reported.
I right clicked on LibreOffice and selected "open." I was presented with the dialog telling me that Apple could not verify the application. I clicked the "Open" button on that dialog and LibreOffice opened.
This is not the behavior I say before. I don't know if something changed or if I was mistaken before.
(In reply to Fred from comment #20)
> That appears to conflict with what I found.
Maybe we are misunderstanding each other. I am only talking about signature verification, not the fact that you can still run LibreOffice after having installed a language pack.
> I'm not sure what is validated by Apple
Well, I am, because of the command that I have given you. Once you find the time to test for yourself, you'll find that after having installed a language pack, LibreOffice no longer successfully passes verification. This may not be of consequence *right now* but may turn into a problem later.
So this was meant as a tip to help with the often not-so-clear situation of what the CLI tools (can) report.
I can confirm that LO6322 will not open without forcing / bypassing the security settings
even when "AppleStore and other identified Developers" option is selected in Gatekeeper security.
Tested on :
macOS Catalina 10.15 (updated to 16/10/2019)
without any additional language pack installation.
If you try and start the app from the Applications folder, you get a security message that indicates the app doesn't come from an identified developer.
You can force this to work in at least the following 2 ways :
(1) right-mouse button click and choose Open then confirm when the next message displays that you want to start LO ;
(2) go into System Prefs, Security, and note that the LO app bundle is flagged as being from an unidentified developer. Click on the Open button. You will be asked to enter your admin password, then you will be presented with the message from option (1) asking you to confirm that you wish to open the app.
After a first successful launch, LO will open on subsequent occasions via double-click on the app bundle in the Applications folder.
Confirming and marking as regression.
The question then is why the LO6322 app bundle is considered by macOS 10.15 as not coming from an identified developer ?
> Confirming and marking as regression.
not a regression IMHO as it never worked on Catalina and works just fine in 10.14 or 10.13.
> The question then is why the LO6322 app bundle is considered by macOS 10.15
> as not coming from an identified developer ?
Well that is the million dollar question, since the logging apple does as well as the commandline tools to inspect the signature all claim that everything is well. As does the notarization report. No issues, no warnings.
$ codesign -vvv --deep --strict ~/Desktop/LibreOffice.app/
[… individual elements all good …]
/Users/cloph/Desktop/LibreOffice.app/: valid on disk
/Users/cloph/Desktop/LibreOffice.app/: satisfies its Designated Requirement
$ spctl -vvv --assess --type exec ~/Desktop/LibreOffice.app/
source=Notarized Developer ID
origin=Developer ID Application: The Document Foundation (7P5S3ZLCN7)
(note: source=*Notarized* Developer ID...)
syspolicyd - subsystem com.apple.security.assessment.outcome2
assessment granted for .app by Notarized Developer ID
com.apple.message.signature: granted:Notarized Developer ID
The only failure is then the worthless
com.apple.xpc.launchd (com.apple.xpc.launchd.oneshot.0x1000000d.soffice): removing service since it exited with consistent failure - OS_REASON_EXEC | Gatekeeper policy blocked execution
So. Everything is OK, but Gatekeeper says: nope (and doesn't tell why - none of the troubleshooting tools give any hint whatsoever) :(((((
(In reply to Christian Lohmaier from comment #24)
In syslog, I also see multiple entries for :
Oct 17 14:25:10 MACMINIMMO soffice: assertion failed: 19A602: libxpc.dylib + 86780 [2E9076CD-6C0E-38B6-8403-B2DDCE125FBF]: 0x89
Oct 17 14:26:05 MACMINIMMO soffice: assertion failed: 19A602: libxpc.dylib + 86780 [2E9076CD-6C0E-38B6-8403-B2DDCE125FBF]: 0x89
Oct 17 14:27:25 MACMINIMMO soffice: assertion failed: 19A602: libxpc.dylib + 86780 [2E9076CD-6C0E-38B6-8403-B2DDCE125FBF]: 0x89
(In reply to Alex Thurgood from comment #25)
> Oct 17 14:25:10 MACMINIMMO soffice: assertion failed: 19A602:
> libxpc.dylib + 86780 [2E9076CD-6C0E-38B6-8403-B2DDCE125FBF]: 0x89
I guess that is after you skip/overrule the gatekeeper check? (no such messages here when not skipping the check)
FYI: no change when creating a build on Catalina with XCode 11 (as to High Sierra with XCode 10) (although build needs some tweaking as DYLD-paths are ignored)
*** Bug 128217 has been marked as a duplicate of this bug. ***
*** Bug 128262 has been marked as a duplicate of this bug. ***
*** Bug 128343 has been marked as a duplicate of this bug. ***
I have the same problem also on two computers with 10.14.x (and I beleive even with previous OS), for more than a year, so this is probably not only Catalina related.
(In reply to Martin Srebotnjak from comment #30)
> Just FYI,
> I have the same problem also on two computers with 10.14.x (and I beleive
> even with previous OS), for more than a year, so this is probably not only
> Catalina related.
"Beginning in macOS 10.14.5, software signed with a new Developer ID certificate and all new or updated kernel extensions must be notarized to run. Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized. However, you aren’t required to notarize software that you distribute through the Mac App Store because the App Store submission process already includes equivalent security checks."
Christian: the same quoted page from my previous comment indicates all steps to notarize an app.
*** Bug 128440 has been marked as a duplicate of this bug. ***
*** Bug 128481 has been marked as a duplicate of this bug. ***
*** Bug 128937 has been marked as a duplicate of this bug. ***
*** Bug 128970 has been marked as a duplicate of this bug. ***
Some web pages (for instance https://medium.com/@mindovermiles262/making-sense-of-apples-notarization-4571af960976) seems to indicate that the application need also a stapled ticket.
I have still not installed Catalina, so I can not check if Catalina find it ; but on Mojave, I get:
> stapler validate /Applications/LibreOffice\ 6.3.app
Processing: /Applications/LibreOffice 6.3.app
LibreOffice 6.3.app does not have a ticket stapled to it.
*** Bug 130727 has been marked as a duplicate of this bug. ***
So what is the plan for this bug now? Is there a plan to fix it or do we have to go and get LibreOffice Vanilla from the Mac AppStore:
cloph: Are we doing all the required steps?
Current instructions say you need to staple the ticket to the binary
On 126.96.36.199 the output I get is:
stapler validate LibreOffice.app/
LibreOffice.app does not have a ticket stapled to it.
So either we don't do the step, or something breaks
(although it says this is only needed for offline validation, but I'
Also there's an issue with the embedded python:
>codesign -vvv --deep --strict LibreOffice.app/
>LibreOffice.app/: a sealed resource is missing or invalid
>In subcomponent: >/Applications/LibreOffice.app/Contents/Frameworks/LibreOfficePython.framework
So that may be what it complains about:
>spctl -vvv --assess --type exec LibreOffice.app/
>LibreOffice.app/: a sealed resource is missing or invalid
Notarizing macOS software:
Customizing the notarization workflow:
Resolving common issues:
>If you use an automated build system, you can integrate the notarization process into your existing build scripts.
>The altool and stapler command-line tools (included with Xcode) allow you to upload your software to the Apple notary service,
>and to staple the resulting ticket to your executable.
The Python issue is definitely holding up the notarization, this was not an issue in comment #24, so we've actually regressed on achieving a proper notarization :)
Use the vvv flag to perform a verification with elevated verbosity. You use the deep flag to ensure the utility checks nested code content. _The strict flag increases the restrictiveness of the validation to match that required by notarization._ See the codesign man page for more information about these flags and how to interpret the output.
Build ID: 4d224e95b98b138af42a64d84056446d09082932
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx;
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Ok there's no crash, it's MacOs specific and some may consider it's not a regression because it's due to new policy from Apple but, considering all the comments, it seems a blocker on MacOs Catalina and future MacOS versions.
Let's put the max priority unless being compatible with MacOS is just a bonus feature.
If someone wants to revert this, please explain why.