Bug 126409 - Notarize LibreOffice builds so that it launches without warnings on macOS 10.15 Catalina
Summary: Notarize LibreOffice builds so that it launches without warnings on macOS 10....
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Mac OS X (All)
: high major
Assignee: Not Assigned
URL: https://developer.apple.com/documenta...
Whiteboard:
Keywords:
: 128217 128262 128343 128440 128481 128937 128970 130727 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-15 18:17 UTC by Pete K.
Modified: 2020-02-17 09:41 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of LangPack error message (38.12 KB, image/png)
2019-09-05 18:47 UTC, Fred
Details
MacOS Catalina warning window (68.52 KB, image/png)
2019-09-26 11:51 UTC, Fred
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pete K. 2019-07-15 18:17:46 UTC
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.
Comment 1 Alex Thurgood 2019-07-17 06:57:24 UTC
@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
Comment 2 Alex Thurgood 2019-07-17 10:28:51 UTC
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.
Comment 3 Xisco Faulí 2019-07-17 10:35:36 UTC
You can get LibreOffice 6.3.0.1 for Mac here -> https://downloadarchive.documentfoundation.org/libreoffice/old/6.3.0.1/mac/x86_64/
Comment 4 Pete K. 2019-07-17 12:50:55 UTC
I confirmed that 6.3.0.1 (from the link that Xisco Faulí provided) launches and runs fine.  When is 6.3 scheduled for general availability?
Comment 5 Xisco Faulí 2019-07-17 13:37:38 UTC
(In reply to Pete K. from comment #4)
> I confirmed that 6.3.0.1 (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
Comment 6 Fred 2019-09-05 18:39:23 UTC
Just installed production 6.3.1.2 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.
Comment 7 Fred 2019-09-05 18:47:34 UTC
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.
Comment 8 Alex Thurgood 2019-09-06 08:53:10 UTC
Hmm, the switch back to XCode 9 for the release of LO631 seems not to allow for proper notarization under Apple's new rules...
Comment 9 Xisco Faulí 2019-09-26 11:14:59 UTC
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
Comment 10 Fred 2019-09-26 11:51:37 UTC
Created attachment 154540 [details]
MacOS Catalina warning window

Alas, still present.

File tested: 
master~2019-09-23_10.09.20_LibreOfficeDev_6.4.0.0.alpha0_MacOS_x86-64.dmg
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?
Comment 11 MattJ 2019-10-09 07:21:10 UTC
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:

uname -a
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/
/Applications/LibreOffice.app/: accepted
source=Notarized Developer ID
origin=Developer ID Application: The Document Foundation (7P5S3ZLCN7)
Comment 12 Buovjaga 2019-10-09 10:14:52 UTC
Pete, Fred, MattJ:
Did you install a language pack before launching LibreOffice first?
Comment 13 MattJ 2019-10-09 12:16:09 UTC
(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?
Comment 14 Buovjaga 2019-10-09 13:00:38 UTC
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.
Comment 15 MattJ 2019-10-09 19:48:37 UTC
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.
Comment 16 Uwe Auer 2019-10-10 18:17:04 UTC
Now Catalina has been released and number of reports in ask.libreoffice.org about this issue is increasing as Catalina gets installed.
 
https://ask.libreoffice.org/en/question/212404/apple-catalina-will-not-open-libreoffice-v627/

https://ask.libreoffice.org/en/question/212093/libreoffice-does-not-start-on-macos-catalina/
Comment 17 Fred 2019-10-10 19:22:41 UTC
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.
Comment 18 Fred 2019-10-11 05:20:27 UTC
Just installed version: 6.3.2.2 (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.
Comment 19 René de Hesselle 2019-10-14 20:54:34 UTC
(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.
Comment 20 Fred 2019-10-15 18:13:17 UTC
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.
Comment 21 MattJ 2019-10-15 19:04:05 UTC
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.
Comment 22 René de Hesselle 2019-10-15 22:17:18 UTC
(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.
Comment 23 Alex Thurgood 2019-10-16 08:31:34 UTC
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 ?
Comment 24 Christian Lohmaier 2019-10-16 15:51:53 UTC
> 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.

On Catalina:

$ 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/
/Users/cloph/Desktop/LibreOffice.app/: accepted
source=Notarized Developer ID
origin=Developer ID Application: The Document Foundation (7P5S3ZLCN7)

(note: source=*Notarized* Developer ID...)

syslog entry:
syspolicyd - subsystem com.apple.security.assessment.outcome2
  
assessment granted for .app by Notarized Developer ID
com.apple.message.domain: com.apple.security.assessment.outcome2
com.apple.message.signature2: bundle:org.libreoffice.script
com.apple.message.signature3: .app
com.apple.message.signature5: 6.3.2002
com.apple.message.signature4: 1
com.apple.message.signature: granted:Notarized Developer ID
SenderMachUUID: 809E062A-31BD-368E-9296-D97CA7A4DF4A


The only failure is then the worthless

com.apple.xpc.launchd[1] (com.apple.xpc.launchd.oneshot.0x1000000d.soffice[2263]): 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) :(((((
Comment 25 Alex Thurgood 2019-10-17 13:43:23 UTC
(In reply to Christian Lohmaier from comment #24)

In syslog, I also see multiple entries for :

Oct 17 14:25:10 MACMINIMMO soffice[16610]: assertion failed: 19A602: libxpc.dylib + 86780 [2E9076CD-6C0E-38B6-8403-B2DDCE125FBF]: 0x89
Oct 17 14:26:05 MACMINIMMO soffice[16616]: assertion failed: 19A602: libxpc.dylib + 86780 [2E9076CD-6C0E-38B6-8403-B2DDCE125FBF]: 0x89
Oct 17 14:27:25 MACMINIMMO soffice[16635]: assertion failed: 19A602: libxpc.dylib + 86780 [2E9076CD-6C0E-38B6-8403-B2DDCE125FBF]: 0x89
Comment 26 Christian Lohmaier 2019-10-17 14:50:34 UTC
(In reply to Alex Thurgood from comment #25)
>
> Oct 17 14:25:10 MACMINIMMO soffice[16610]: 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)
Comment 27 Alex Thurgood 2019-10-18 12:41:43 UTC
*** Bug 128217 has been marked as a duplicate of this bug. ***
Comment 28 Alex Thurgood 2019-10-21 11:39:10 UTC
*** Bug 128262 has been marked as a duplicate of this bug. ***
Comment 29 Xisco Faulí 2019-10-23 13:35:07 UTC
*** Bug 128343 has been marked as a duplicate of this bug. ***
Comment 30 Martin Srebotnjak 2019-10-24 09:49:11 UTC
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.
Comment 31 Julien Nabet 2019-10-26 11:53:12 UTC
(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.

From https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution:
"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."
Comment 32 Julien Nabet 2019-10-26 11:57:31 UTC
Christian: the same quoted page from my previous comment indicates all steps to notarize an app.
Comment 33 m.a.riosv 2019-10-28 23:39:26 UTC
*** Bug 128440 has been marked as a duplicate of this bug. ***
Comment 34 Xisco Faulí 2019-10-30 16:02:47 UTC
*** Bug 128481 has been marked as a duplicate of this bug. ***
Comment 35 Alex Thurgood 2019-11-22 08:20:01 UTC
*** Bug 128937 has been marked as a duplicate of this bug. ***
Comment 36 Alex Thurgood 2019-11-23 05:40:20 UTC
*** Bug 128970 has been marked as a duplicate of this bug. ***
Comment 37 osnola 2019-12-10 09:53:13 UTC
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.
Comment 38 Buovjaga 2020-02-17 09:37:59 UTC
*** Bug 130727 has been marked as a duplicate of this bug. ***