Looks like several of the recent LO drops for Mac don't run `python` anymore. Output from my console: > uname -a Darwin pooh 22.6.0 Darwin Kernel Version 22.6.0: Thu Apr 24 20:25:14 PDT 2025; root:xnu-8796.141.3.712.2~1/RELEASE_X86_64 x86_64 i386 Darwin And various LO versions: > LibreOffice.app/Contents/MacOS/soffice --version LibreOffice 24.2.5.2 bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 > LibreOffice.app/Contents/Resources/python Python 3.8.19 (default, Jul 10 2024, 18:17:37) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ^D and > LibreOffice.app/Contents/MacOS/soffice --version LibreOffice 25.2.4.3 33e196637044ead23f5c3226cde09b47731f7e27 > LibreOffice.app/Contents/Resources/python Killed: 9 and > LibreOffice.app/Contents/MacOS/soffice --version LibreOffice 25.2.5.2 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 > LibreOffice.app/Contents/Resources/python Killed: 9 and > LibreOffice.app/Contents/MacOS/soffice --version LibreOffice 25.8.0.2 80a8bc2ef75d415a197e282da0ebf917315d5e24 > LibreOffice.app/Contents/Resources/python Killed: 9 I've not tried others. Thanks, Jens
Confirming also with Version: 25.8.1.1 (AARCH64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 8; OS: macOS 15.6.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded and attaching an Apple crash trace. ==> regression
Created attachment 202594 [details] LO python launch crash
*** Bug 167645 has been marked as a duplicate of this bug. ***
Description from bug 167645: Apparently, this commit blocked the execution of embedded Python from outside LibreOffice: https://gerrit.libreoffice.org/c/core/+/185792
marking this as duplicate of 167645 - it is an intentional change, since otherwise LibreOffice's permissions that the user grants to LibreOffice could be abused by random other processes, in effect bypassing macOS security. I honestly don't really have a good idea on how to solve this dilemma - for now using your own python runtime (or initiating the calls via LibreOffice) are the only options. Of course open for ideas on how this can be solved technically without nullifying that measure... https://developer.apple.com/documentation/security/applying-launch-environment-and-library-constraints is starting point for Apple's docs. I guess it could help to have concrete use case description as for what the python runtime shipped with LibreOffice should be used for when called externally. Document conversion can be done by launching a macro/entry point via LibreOffice. https://wiki.documentfoundation.org/Documentation/DevGuide/Scripting_Framework#Python_script e.g. 'vnd.sun.star.script:TableSample.py$createTable?langauge=Python&location=share' for the one of the samples that create a new writer document and inserts some text and a table. So the workaround would be to create an extension that does what you want and deploy that, then you can call the script from the extension (or place the files manually)
Hello everybody, Sorry but I do'nt understand. Until LO 25.2 it was possible to use the LO python exec from outside (importing uno etc) with problem of security. And it will not be available with LO 25.8 For me, it's a big regression. If needed, I can provide MSExcel or Word VBA macro witch run LO Basic function and retrieve the result in Excel or MSWord. Who can explain to me how to use an "outside" python exec, importing uno etc. I did not find. Thanks for your works.
(In reply to Dorange-Pattoret Didier from comment #6) https://gerrit.libreoffice.org/c/core/+/185792?tab=comments Unfortunately, there isn't much of an explanation in those comments as to why the ParentLaunchConstraint was added. Reading between the lines, it is my understanding that it is linked to an issue with code signing of the app bundle, whereby in order for all of the executable parts, which are included in the app bundle on build, to inherit the developer certificate signature, then a process launch constraint had to be introduced to prevent launching of pyuno from a python process outside of the main LO app process.
(In reply to Alex Thurgood from comment #7) > (In reply to Dorange-Pattoret Didier from comment #6) > > https://gerrit.libreoffice.org/c/core/+/185792?tab=comments > > Unfortunately, there isn't much of an explanation in those comments as to > why the ParentLaunchConstraint was added. > > Reading between the lines, it is my understanding that it is linked to an > issue with code signing of the app bundle, whereby in order for all of the > executable parts, which are included in the app bundle on build, to inherit > the developer certificate signature, then a process launch constraint had to > be introduced to prevent launching of pyuno from a python process outside of > the main LO app process. Such an outside process would be Terminal.app, hence why you can no longer call /Applications/LibreOffice.app/Contents/Resources/python without causing a crash and a launch constraint violation: "Namespace CODESIGNING, Code 4, Launch Constraint Violation"
(In reply to Dorange-Pattoret Didier from comment #6) The only way to avoid this launch constraint, according to: https://eclecticlight.co/2024/08/23/why-launch-constraints-can-crash-apps/ is to turn off SIP (system integrity protection).
Hello Everybody, I tried to use an external python executable. I didn't find how to import uno. So, I think this bug-regression is a very big problem ... Didier DP.