Signing them as executable code would require external attributes, and
those in turn break packaging into hfs+ dmg when building on apfs with
Big Sur.
It is not a new thing - the old Code Signing in Depth technote
https://developer.apple.com/library/archive/technotes/tn2206/_index.html
already reads:
"Store Python, Perl, shell, and other script files and other non-Mach-O
executables in your app's Contents/Resources directory. While it's
possible to sign such executables and store them in Contents/MacOS, this
is not recommended.
[…]
Put another way, a properly-signed app that has all of its files in the
correct places will not contain any signatures stored as extended
attributes."
The patch does exactly that for LO and the shipped python framework and
adds symlinks for the moved files.
Same applies for the Language pack applescript and the tarball - those
are also moved into Contents/Resources
Change-Id: Iab21e77b73f941248ca89c6e80703fdf67a1057c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109537
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2009-08-18 16:35:06 +0200 is r275118 : #i102939# differ between ok-label and install-label
2009-08-13 17:24:47 +0200 is r274960 : #i102939# mac languagepacks
2009-08-13 17:22:22 +0200 is r274959 : #i102939# mac languagepacks
2009-08-13 17:15:01 +0200 is r274958 : #i102939# mac languagepacks
2009-08-13 17:13:36 +0200 is r274957 : #i102939# mac languagepacks
2009-08-13 17:12:57 +0200 is r274956 : #i102939# mac languagepacks
2009-08-13 17:12:20 +0200 is r274955 : #i102939# mac languagepacks
2009-08-13 17:11:41 +0200 is r274954 : #i102939# mac languagepacks
2009-08-13 17:10:52 +0200 is r274953 : #i102939# mac languagepacks
Christian Lohmaier