On Thu, Mar 12, 2026 at 5:59 PM Calvin Buckley <[email protected]> wrote:
> On Mar 11, 2026, at 7:06 PM, Andrey Andreev <[email protected]> wrote: > > > > > I want to add one more side-effect that feels discounted: PII and other > sensitive data leaking through logs. Partly what the INI setting is > supposed to address, but IMO it only does so on paper. > > I have dealt with that issue many times, and developers tend to either > not take it seriously or propose naive patchwork solutions such as > blacklisting patterns in already produced logs. Plus, there's an inherent > temptation to temporarily enable such settings for debugging purposes, not > realizing the act itself represents a data leak and it is permanent. If > this is a serious problem without args values being present today, imagine > the amplification effect from this addition. > > > > With that being said, I also know the pain of having to deal with > borderline useless error messages. The proposal isn't without merit, but > I'd look for alternative approaches that don't create security headaches. > > This is something I'm also concerned about, but I feel the cat is > already out of the bag with backtraces in exceptions providing the same > parameter information. PHP and the library ecosystem seem to be adopting > the sensitive parameter attribute, so my hope is that applications also > start adopting it. On one hand, it's true that the cat is already out of the bag. On the other, that's been the case since at least the days of PHP 4 and related effort since has been to limit the danger. This would be a first in the other direction. Semi-random idea: what if it was a declare statement instead of an INI? That would have multiple benefits: - Can limit the exposure to particular scripts rather than globally - Easy to spot during code reviews and therefore little danger of negligent leaks - Potential to consolidate backtraces under the same umbrella and eventually retire zend.exception_ignore_args Cheers, Andrey.
