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 6.3.0.1 for Mac here -> https://downloadarchive.documentfoundation.org/libreoffice/old/6.3.0.1/mac/x86_64/
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?
(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
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.
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. 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?
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)
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. 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/
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: 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.
(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. 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) :(((((
(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
(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)
*** 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. ***
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.
(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."
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: https://apps.apple.com/cn/app/libreoffice-vanilla/id921923693?l=en&mt=12
cloph: Are we doing all the required steps? Current instructions say you need to staple the ticket to the binary On 6.4.1.2 the output I get is: stapler validate LibreOffice.app/ Processing: /Applications/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: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution Customizing the notarization workflow: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow Resolving common issues: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_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. Version: 6.4.1.2 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 Calc: threaded
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.
The same issue still reproducible on Libreoffice 6.4.2.2: $ cat LibreOffice.app/Contents/Info.plist | grep -i "LibreOffice 6" <string>LibreOffice 6.4.2.2</string> $ /Applications stapler validate LibreOffice.app Processing: /Applications/LibreOffice.app LibreOffice.app does not have a ticket stapled to it. $ codesign -vvv --deep --strict LibreOffice.app ........... LibreOffice.app: a sealed resource is missing or invalid In subcomponent: /Applications/LibreOffice.app/Contents/Frameworks/LibreOfficePython.framework ...........
> Langpack installer installs additional files to the app directory That is and has always been a HORRIBLE idea. The intent has always been, I assume, that an app bundle should be read-only, even if it has not been enforced. Installing a separate langpacks should put it into ~/Library for instance. (No, I am not volunteering to fix this. I work on the App Store build, which comes with a set of bundled langpacks.)
I see Python mentioned. If the problem is that Python writes bytecode files into the app bundle, would 4e124fd1409af419990bacade74fcf355624243f help? Are the notarized builds configured with --enable-readonly-installset?
I really don't know anything about this at all, but saw a reference to a helper app for notarizing that may help solve this? https://github.com/akeru-inc/xcnotary From this comment chain: https://news.ycombinator.com/item?id=23086538
I wrote: > No, I am not volunteering to fix this But I did not have to volunteer, I am now in the progress of fixing it as part of my job.
Created attachment 161165 [details] no problem with notarization on my fresh Catalina... can anyone actually reproduce the Gatekeeper issue/not showing notarization with a current version of Catalina and current version of LibreOffice? Messing with the .app directory comes after gatekeeper, so checking signatures after installing languagepack is expected to not show clean result. I could reproduce it when Catalina first came out, but not with a clean installation I did today (no build-environment or other stuff installed) "Apple hat sie auf Malware überprüft und keine gefunden" → the string you get when it was successfully notarized (Apple checked it for malware and couldn't find any)
Created attachment 161186 [details] Failed code sign due to Python framework The code-signing shows non-clean results on a fresh install (no language pack), no ticket is stapled, and the command line tool does not report LO as notarised >spctl -vvv --assess --type exec LibreOffice.app/ >LibreOffice.app/: a sealed resource is missing or invalid See attachment for full output >codesign --verify --deep --verbose LibreOffice.app/ >LibreOffice.app/: a sealed resource is missing or invalid In subcomponent: This is a regression from when you tested this autumn in comment #24 I haven't opened a new bug about that as the issues are a bit related, or? As per comment #41 passing -vvv is a requirement for notarisation: _The strict flag increases the restrictiveness of the validation to match that required by notarization._ Also, LO should possibly have the ticket stapled to it: >> a degraded user experience, as the first time a user runs a new executable, >>Apple delays execution while waiting for a reply from their server. >The way to avoid this behavior is to staple the notarization ticket to your >bundle (or dmg/pkg), i.e. "/usr/bin/stapler staple <path>." >Otherwise, Gatekeeper will fetch the ticket and staple it for the user >on the first run. >I'm the author of xcnotary [1], a tool to make notarization way less >painful, including uploading to Apple/polling for >completion/stapling/troubleshooting various code signing issues.) >[1] https://github.com/akeru-inc/xcnotary https://news.ycombinator.com/item?id=23273396 >stapler validate LibreOffice.app/ >Processing: /Applications/LibreOffice.app >LibreOffice.app does not have a ticket stapled to it. For some reason there's no ticket stapled after first run either, which indicates it's not fully compliant given what the author of the xcnotary tool says? --- Checking another popular open source app, Firefox, seems to have everything working in contrast to LO. Opening the app for the first time does not show a "verify" progress bar as LO does, and all the required steps above are satisified (all of these fail on LO) >stapler validate Firefox.app/ >Processing: /Applications/Firefox.app >The validate action worked! >spctl -vvv --assess --type exec Firefox.app/ >Firefox.app/: accepted >source=Notarized Developer ID >origin=Developer ID Application: Mozilla Corporation (43AQ936H96) >codesign --verify --deep --verbose Firefox.app/ >Firefox.app/: valid on disk >Firefox.app/: satisfies its Designated Requirement
(In reply to eisa01 from comment #49) > Created attachment 161186 [details] > Failed code sign due to Python framework Creation of compiled py files (pyc) is also something that only happens after LO was launched. So similar to the languagepack installation it is a post-gatekeeper modification of the .app bundle. Not nice, for sure, but unrelated to gatekeeper/notarization when doing the first-launch verification by macOS a .app copied from the dmg to your local disk before launching it should verify: cloph@Catalina-Mac-mini Desktop % spctl -vvv --assess --type exec LibreOffice.app/ LibreOffice.app/: accepted source=Notarized Developer ID origin=Developer ID Application: The Document Foundation (7P5S3ZLCN7) cloph@Catalina-Mac-mini Desktop % codesign --verify --deep --verbose LibreOffice.app/ LibreOffice.app/: valid on disk LibreOffice.app/: satisfies its Designated Requirement cloph@Catalina-Mac-mini Desktop % (and launching it for the first time should show the dialog with the "..downloaded from... checked by apple for malware and none was found" dialog.) After having launched LO (or more specifically: doing something that triggers initialization of python, i.e. opening/creating a writer document → some writing aids use python → python creates it pyc files) I can confirm the python files messing up the integrity on disk, but as said: that is after LO was already green-lit by gatekeeper. ######### stapling ########### as for stapling: In LO's case: the thing you download is stapled, not just the contents, so the dmg has the notarization-staple-info for the app assigned to it. ### > Opening the app for the first time does not show a "verify" progress bar as LO does, likely because the Firefox app is too small/the scanning is fast enough to not make it trigger a dialog for that. If you mean verify progress when opening the dmg: that happens for firefox as well/any dmg, but that is just checksum based verification of the dmg for download errors.
Tested LO 6.4.4 on macOS 10.15.4 and all checks were fine. No problem after re-installing 6.4.4 to open on macOS. The expected dialog to visit website (from which download was made) or cancle or open app was shown and LO opened fine on first attempt. Considering the findings above I claim this bug here is worksforme.
steve, so are you saying that this bug, that LibreOffice builds should be notarized, is invalid, as it works for you anyway? Interesting.
(In reply to Christian Lohmaier from comment #50) > Creation of compiled py files (pyc) is also something that only happens > after LO was launched. So similar to the languagepack installation it is a > post-gatekeeper modification of the .app bundle. Not nice, for sure, but > unrelated to gatekeeper/notarization when doing the first-launch > verification by macOS Ah, ok > > a .app copied from the dmg to your local disk before launching it should > verify: Yup, I can also see that now > (and launching it for the first time should show the dialog with the > "..downloaded from... checked by apple for malware and none was found" > dialog.) > > After having launched LO (or more specifically: doing something that > triggers initialization of python, i.e. opening/creating a writer document → > some writing aids use python → python creates it pyc files) I can confirm > the python files messing up the integrity on disk, but as said: that is > after LO was already green-lit by gatekeeper. But I guess we have no guarantee that it doesn't cause problems (e.g., the mysterious save-as issues) At least after those python files are created, macOS doesn't treat the .app as notarised any more if it does a recheck. Who knows when that happens, or if the behaviour will change in a future system update > ######### stapling ########### > as for stapling: In LO's case: the thing you download is stapled, not just > the contents, so the dmg has the notarization-staple-info for the app > assigned to it. > > ### > > Opening the app for the first time does not show a "verify" progress bar as LO does, > > likely because the Firefox app is too small/the scanning is fast enough to > not make it trigger a dialog for that. If you mean verify progress when > opening the dmg: that happens for firefox as well/any dmg, but that is just > checksum based verification of the dmg for download errors. Ah, true. Thanks for explaining all of this! ---- So in a nutshell: LO is notarised on first launch, but as soon as you do something the .app bundle is corrupted and the .app is no longer notarised So technically WFM, but I'm not sure there's any point in creating a new bug "Notarisation corrupted" of "highest/critical" rating and readding everyone to CC from this bug?
I installed 6.4.4.2 on the same system I had problem with before. This time it started with the expected warning that the application was downloaded from the internet. Once I clicked OK on that dialog LO opened with no problem. I did not get any warnings about Apple not being able to verify it. This works for me now. I think it can be closed.
But the LibreOffice.app one downloads from TDF is still not notarized, is it? So in what way could this bug be seen as resolved? Even if it apparently now is still possible, after all, to run non-notarized (only signed) 3rd-party software downloaded from random sites, isn't the point that this might change at some point and it would be good to be prepared for that, and not desperately then try to fix it when the problem materializes for real? It shouldn't be hard to understand that Apple wants to continuouslu increase the security of macOS. As such, personally, I much prefer the App Store as a distribution channel for macOS software. LibreOffice Vanilla has been available there for several years.
(In reply to Tor Lillqvist from comment #55) > But the LibreOffice.app one downloads from TDF is still not notarized, is > it? No - all mac builds for 6.3 and later versions you can download from www.libreoffice.org are notarized. Daily builds created by tinderboxes are not signed at all and therefore also not notarized. > So in what way could this bug be seen as resolved? The question is: why is this still open. And the answer is: mixing of different stuff. Problem initially was with Gatekeeper in macOS Catalina. A bug in Catalina's gatekeeper. That still claimed that it was not notarized despite having been notarized and the commandline tools (spctl, codesign, stapler) all confirming that. If you get the message "has been checked by Apple for malware" when opening (and are able to launch it without going to system settings and set a security exception or using alt-open to add the exception that way): that is the end-user visible proof of successful notarization. Confirmed by multiple persons that gatekeeper in current version of Catalina no longer (falsely) accuses the App of not being notarized → resolving WFM. As for stapling the info the dmg and not the app included in the dmg container: also expected/as designed: https://github.com/akeru-inc/xcnotary/issues/3#issuecomment-622022976 > Our general advice here is that you sign everything, from the inside out, and > then notarise and staple the outermost container. That ticket covers all the > code included in the container. When Gatekeeper checks the code signature of > the container, it will ingest the ticket, avoiding the need for a round trip > to the notary service on first run. As to .app folder being modified post-gatekeepr/notarization checks: Those already have corresponding separate bugs, but those are unrelated to gatekeeper and notarization. That's only checked on first launch.