On Sat, Aug 1, 2026 at 10:11 PM Sjoerd Langkemper <[email protected]>
wrote:

> Hello list,
>
> I would like to reduce the chance that sensitive information passed to
> curl_setopt is leaked. There's the SensitiveParameter attribute to prevent
> parameters being exposed in stack traces. For example, openssl_encrypt has
> its passphrase parameter marked as SensitiveParameter, so it won't be shown
> in a stack trace. This mechanism doesn't work so well for curl_setopt,
> which has the ability to set many options, both sensitive and not. The
> value for CURLOPT_PASSWORD is likely sensitive, the value for
> CURLOPT_RETURNTRANSFER is not, and CURLOPT_URL may be sensitive sometimes.
>
> I have thought of the following solutions:
>
>    1. Mark the parameter as SensitiveParameter. This improves security,
>    but also obscures non-sensitive information. I am not sure how big of a
>    disadvantage that actually is? The curl error messages could already use
>    improvement, but when the value is hidden (because it's sensitive) it
>    becomes even more important to provide better errors.
>    2. Let curl_setopt determine whether to mark the parameter as
>    sensitive, depending on which option is being set. This is nice
>    functionally, but needs changes in the engine to store sensitivity of each
>    parameter in the stack, which comes with performance costs.
>    https://github.com/php/php-src/pull/22938
>    3. Be able to pass a SensitiveParameterValue to curl_setopt. This puts
>    the burden on the user to correctly wrap their sensitive values.
>    https://github.com/php/php-src/pull/22960
>
> What do you think?
>
> Regards,
>
> Sjoerd
>


Stack traces are available on dev machines only unless everything is
misconfigured so I don't see how it can leak something. Imagine you
request an API with the wrong password because a co-worker changed it. How
would you know? Just my 2 cents.

-- 
Iliya Miroslavov Iliev
[email protected]

Reply via email to