<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Notarize LibreOffice builds so that it launches without warnings on macOS 10.15 Catalina"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=126409#c49">Comment # 49</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Notarize LibreOffice builds so that it launches without warnings on macOS 10.15 Catalina"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=126409">bug 126409</a>
from <span class="vcard"><a class="email" href="mailto:eisa01@gmail.com" title="eisa01 <eisa01@gmail.com>"> <span class="fn">eisa01</span></a>
</span></b>
<pre>Created <span class=""><a href="http://bugs.documentfoundation.org/attachment.cgi?id=161186" name="attach_161186" title="Failed code sign due to Python framework">attachment 161186</a> <a href="http://bugs.documentfoundation.org/attachment.cgi?id=161186&action=edit" title="Failed code sign due to Python framework">[details]</a></span>
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
<span class="quote">>spctl -vvv --assess --type exec LibreOffice.app/
>LibreOffice.app/: a sealed resource is missing or invalid</span >
See attachment for full output
<span class="quote">>codesign --verify --deep --verbose LibreOffice.app/
>LibreOffice.app/: a sealed resource is missing or invalid</span >
In subcomponent:
This is a regression from when you tested this autumn in <a href="show_bug.cgi?id=126409#c24">comment #24</a>
I haven't opened a new bug about that as the issues are a bit related, or?
As per <a href="show_bug.cgi?id=126409#c41">comment #41</a> 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:
<span class="quote">>> 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] <a href="https://github.com/akeru-inc/xcnotary">https://github.com/akeru-inc/xcnotary</a></span >
<a href="https://news.ycombinator.com/item?id=23273396">https://news.ycombinator.com/item?id=23273396</a>
<span class="quote">>stapler validate LibreOffice.app/
>Processing: /Applications/LibreOffice.app
>LibreOffice.app does not have a ticket stapled to it.</span >
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)
<span class="quote">>stapler validate Firefox.app/
>Processing: /Applications/Firefox.app
>The validate action worked!</span >
<span class="quote">>spctl -vvv --assess --type exec Firefox.app/
>Firefox.app/: accepted
>source=Notarized Developer ID
>origin=Developer ID Application: Mozilla Corporation (43AQ936H96)</span >
<span class="quote">>codesign --verify --deep --verbose Firefox.app/
>Firefox.app/: valid on disk
>Firefox.app/: satisfies its Designated Requirement</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>