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.

The lack of communication vis-à-vis end users is probably not helping.

I would be inclined to mark this as a DUP of bug 162677

(In reply to Alex Thurgood from comment #11)
> The lack of communication vis-à-vis end users is probably not helping.
> 
> I would be inclined to mark this as a DUP of bug 162677

Forget that, the above comment can be deleted.

*** Bug 168739 has been marked as a duplicate of this bug. ***

Bumping importance, as this is kind of a major hamstring regression for any kind of python automation with LO on macOS.

Guess I can only repeat what I wrote in comment#5 – it is an deliberate change to respect macOS security architecture, and I don't know a way to solve that problem without undoing that fix. See https://www.libreoffice.org/about-us/security/advisories/cve-2025-14714/ 

There are workarounds I mentioned:

####

call your entry point from a python macro you install as an extension or put into the scripts folder.

https://wiki.documentfoundation.org/Documentation/DevGuide/Scripting_Framework#Python_script

concrete example: 'vnd.sun.star.script:TableSample.py$createTable?langauge=Python&location=share' will be the createTable macro that will create a writer document and insert a table.

###

second option is of course to compile LibreOffice yourself without the launch constraint – then none of the checks apply and it will behave as before

###

third option is to do a python runtime you install/provide independent of LibreOffice.
you can start LibreOffice with parameters to listen on a socket or pipe and communicate that way, that still will work. https://wiki.documentfoundation.org/Documentation/DevGuide/Professional_UNO#Starting_LibreOffice_in_Listening_Mode

###

If anyone has a technical suggestion on how to make it work while respecting the "Transparency, Consent, and Control (TCC) permissions" I'm all ears – but I just don't know a way.

>If anyone has a technical suggestion on how to make it work while respecting the "Transparency, Consent, and Control (TCC) permissions" I'm all ears – but I just don't know a way.

Reminds me to a similar problem in GIMP on macOS relating the app-bundled python. Maybe the discussion and comments there, their obstacles and their partially solution and patches might be helpful also for resolving the issue for LibreOffice on macOS or get a new idea for resolving the issue in LibreOffice:

GIMP issue #13848: Local Privilege Escalation - TCC Bypass via Inherited Permissions in Bundled Interpreter in GIMP.app 
https://gitlab.gnome.org/GNOME/gimp/-/issues/13848

See also latest comments and latest/note by Lukas Oberhuber (one of GIMP's macOS maintainers and macOS build engineer):
https://gitlab.gnome.org/GNOME/gimp/-/issues/13848#note_2541524

GIMP issue #14795: [macOS] GIMP hangs on intel
https://gitlab.gnome.org/GNOME/gimp/-/issues/14795

See also and in particular the comments from here on:
https://gitlab.gnome.org/GNOME/gimp/-/issues/14795#note_2537628

Hope, it helps or can give a new idea, and my feeling/guessing is not distracting, that it might be around a very similar problem concerning launching the embedded python and handling the TCC.

Here is workaround:

# Extract the python from LibreOffice directory, and replace the signature:


mkdir -p "$HOME/libreoffice-python"

cp -R /Applications/LibreOffice.app/Contents/Resources "$HOME/libreoffice-python/"

cp -R /Applications/LibreOffice.app/Contents/Frameworks "$HOME/libreoffice-python/"

codesign --force --deep --sign - "$HOME/libreoffice-python/Frameworks/LibreOfficePython.framework/Versions/3.12/Resources/Python.app"

codesign --force --deep --sign - "$HOME/libreoffice-python/Frameworks/LibreOfficePython.framework"


# Verify that it is running without error:

$HOME/libreoffice-python/Resources/python -c 'import uno, sys; print("uno=", uno.__file__)'

(In reply to david from comment #17)

> 
> codesign --force --deep --sign -
> "$HOME/libreoffice-python/Frameworks/LibreOfficePython.framework/Versions/3.
> 12/Resources/Python.app"
> 

Thanks for your help.
I tried your workarround and got an arror in the below line :

error: The specified item could not be found in the keychain

What can I do ?
Best regards.

Still happening with LibreOffice_25.8.6_MacOS_x86-64 and LibreOffice_26.2.2_MacOS_x86-64.

> 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. 

I need to import uno and use it to talk to the LO process from Python, load documents, etc. On Linux it works to use system Python and then expand the PYTHONPATH to find uno; however, on macOS that does not work and instead using LO’s own Python used to work…

*** Bug 172921 has been marked as a duplicate of this bug. ***