PR: https://github.com/mantisbt/mantisbt/pull/2175

Now, for example, if you specify an unavailable font (e.g. $g_relationship_graph_fontname = 'Foobar';), a warning will be displayed.

foobar-font-warning.png (33,534 bytes)   

foobar-font-warning.png (33,534 bytes)   

I have some doubts. I've read about the challenges of running external utilities correctly and without deadlocks in PHP, especially if they use stderr and output a lot of data to stdout. Perhaps we should delegate this task to Symfony Process (composer require symfony/process).

Alternatively, we can port the rendering of graphs to Viz.js. https://viz-js.com/

the old code unnecessarily creates a temporary file for each utility call.

As you mentioned in 0036859:0070746, he reason is to avoid deadlocks when using pipes on Windows, as I wrote earlier today in the PR review. I reproduce my note here for the record:

I agree it's a bit of an ugly hack to use a temp file for this, but it works and is very reliable.

For the record, this was implemented as a workaround for a locking problem with the stderr pipe under Windows, causing the program to hang. Using non-blocking pipes (stream_set_blocking()) did not help, and neither did reading stderr first and then closing the stream.

I was on PHP 5.x at the time, so maybe recent PHP versions are handling this correctly, I don't know. But according to this 2-year-old comment comment on PHP documentation, it is not the case and the locking problem still exists and is unlikely to go away...

calling stream_set_blocking() on pipe handles returned by proc_open() will actually do nothing on Windows. We can derive from these facts that PHP does not have a non-blocking implementation for pipes on Windows and will therefore block/deadlock when using proc_open().

Unfortunately I no longer have access to the environment that suffered from this and don't remember the details or steps to reproduce the problem so I can't test, but I'm reluctant to potentielly reintroduce a bug...

Alternatively, we can port the rendering of graphs to Viz.js. https://viz-js.com/

That's a very interesting idea, delegating rendering to the client would reduce not only the code complexity, but also the required effort for admins to setup GraphViz. Probably not a small undertaking though.

I had the courage to redo the PR to use Viz.js. :-)
Essentially, no changes to the GraphViz code were necessary; this JavaScript library is surprisingly well compatible.

Nice ! I'll have a look.

I think I figured out how to reduce the impact of the CSP header "script-src: wasm-unsafe-eval". This header should only be used if the page loads this script. To accomplish this, we need to enable calling http_csp_add(‘script-src’, ‘wasm-unsafe-eval’); not only from core.php: 0036864