Does adding:

$g_show_detailed_errors = ON;
$g_display_errors = array(E_WARNING => 'halt',
                           E_NOTICE => 'halt',
                           E_USER_ERROR => 'halt',
                           E_USER_WARNING => 'halt',
                           E_USER_NOTICE => 'halt');

to config_inc.php resolve this issue?

No, this has no effect.

fixed there:
http://git.mantisforge.org/w/mantisbt/dtschinder.git?a=commit;h=d62133529ead678d31528e965614461b92d12561

I can see what the problem is now, but I'm not sure I agree with the patch.

I think we should be reading the value of error_reporting() and then applying changes from the $g_display_errors setting on top of the PHP defaults.

The patch here seems to force Mantis to trap all predefined PHP error constants with the exception of E_NOTICE as defined at http://www.php.net/manual/en/errorfunc.constants.php

This completely ignores the values set in php.ini which seems wrong to me. I don't mind if Mantis can be configured to overrule the values in php.ini, as long as it is optional (and disabled by default). The exception is the EUSER* errors which are within Mantis' domain - these should be enabled all the time (ignoring php.ini) unless the user specifically disables them via $g_display_errors.

Any thoughts on this?

I committed a patch that adds all EUSER* errors to the error_reporting.
This only adds these errors and leaves all other errors (E_WARNING,E_NOTICE,...) as they are.

http://git.mantisforge.org/w/mantisbt/dtschinder.git?a=commit;h=d30ac1919391577e35301b2a6824dd5ecea8d2de

FYI, fix available at https://github.com/dregad/mantisbt/commit/cec454931df5a99d03ff22aabf8901648ff3d549, testing & feedback welcome

Background: we configure most of our production environments to error_reporting(0) and to make the practise consistent, we configured this for mantis as well. So we encountered this problem too.

Test: I added your fix to our mantis environment and verified that validation result is now respected (i.e. that the trigger_error-call stops further execution of the flow).

Feedback: none really, I like the fix.

Thanks for testing !

Backported to 1.2.x branch as a security fix, as it was identified in 0013990 that in a system with error_reporting = 0, an attacker could gain unauthorized access to the system via verify.php page.

We will not request a CVE for this, as MantisBT (before this fix) is basically not functioning in such a scenario, so it's highly unlikely that someone would run with this configuration for long.