Just saying: in the PHP repository there was an issue about making this#[\SensitiveParameter] feature configurable because in dev/test you probably don't want to hide anything.

Seephp/php-src#8381

@javiereguiluz we should expose theSensitiveParameterValue in Symfony error page and profiler?

I don't know. It was just a "maybe we should think about this" comment.

Imagine a bug where you mistyped some chars in your password. But is that common?

Can you take a look at the rest of the codebase where this could be useful? I think it's fine do it once for all, everywhere plain credentials are passed around (#46853 mentions some relevant places btw)

RFC author here 👋

Can you take a look at the rest of the codebase where this could be useful? I think it's fine do it once for all, everywhere plain credentials are passed around

I recommend not just looking at credentials, but also stuff like plaintext values that are passed into an encryption component to be encrypted. I'm not a Symfony user, but an example would likely beCsrfTokenManager::randomize().

My php-src PR that adds the attribute is this one:php/php-src#8352, it might be a good reference.

I added the attribute on every parameter that looks like a secret.

Notes:

• A DSN string can contain the password. Hiding the whole DSN can hurt debugging.
• Some functions cannot throw an exception or make an error. Adding the annotation may be useless.
• This attribute is not a guarantee that a sensitive value will not be exposed. This values are passed to generic functions that will not have the attribute.

A DSN string can contain the password. Hiding the whole DSN can hurt debugging.

That's ok as long as we manage to reveal the sensitive values in debugging contexts such as the webprofiler, right?

Some functions cannot throw an exception or make an error. Adding the annotation may be useless.

Fine to me as well, as they might do at some point or be extended.

Thank you@GromNaN.