Re: [PHP-DEV] How to handle sensitive parameters to curl_setopt?

--000000000000f18ce90658015394
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 1, 2026 at 10:11=E2=80=AFPM Sjoerd Langkemper <sjoerd-php@linux=
only.nl>
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 preven=
t
> parameters being exposed in stack traces. For example, openssl_encrypt ha=
s
> its passphrase parameter marked as SensitiveParameter, so it won't be sho=
wn
> 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 u=
se
>    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.

--=20
Iliya Miroslavov Iliev
[email protected]

--000000000000f18ce90658015394
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 1, =
2026 at 10:11=E2=80=AFPM Sjoerd Langkemper &lt;<a href=3D"mailto:sjoerd-php=
@linuxonly.nl">[email protected]</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><u></u><div><div>Hello list,</div><di=
v><br></div><div>I would like to reduce the chance that sensitive informati=
on passed to curl_setopt is leaked. There&#39;s the SensitiveParameter attr=
ibute to prevent parameters being exposed in stack traces. For example, ope=
nssl_encrypt has its passphrase parameter marked as=C2=A0SensitiveParameter=
, so it won&#39;t be shown in a stack trace. This mechanism doesn&#39;t wor=
k 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 s=
ometimes.</div><div><br></div><div>I have thought of the following solution=
s:<br></div><ol><li>Mark the parameter as=C2=A0SensitiveParameter. This imp=
roves security, but also obscures non-sensitive information. I am not sure =
how big of a disadvantage that actually is? The curl error messages could a=
lready use improvement, but when the value is hidden (because it&#39;s sens=
itive) it becomes even more important to provide better errors.</li><li>Let=
 curl_setopt determine whether to mark the parameter as sensitive, dependin=
g on which option is being set. This is nice functionally, but needs change=
s in the engine to store sensitivity of each parameter in the stack, which =
comes with performance costs.=C2=A0<a href=3D"https://github.com/php/php-sr=
c/pull/22938" target=3D"_blank">https://github.com/php/php-src/pull/22938</=
a><br></li><li>Be able to pass a=C2=A0SensitiveParameterValue to curl_setop=
t. This puts the burden on the user to correctly wrap their sensitive value=
s.=C2=A0<a href=3D"https://github.com/php/php-src/pull/22960" target=3D"_bl=
ank">https://github.com/php/php-src/pull/22960</a><br></li></ol><div>What d=
o you think?</div><div><br></div><div>Regards,</div><div><br></div><div>Sjo=
erd</div></div></blockquote></div><div><br clear=3D"all"></div><div><br>Sta=
ck traces are available on dev machines only unless everything is misconfig=
ured so=C2=A0I don&#39;t see how it=C2=A0can leak something. Imagine you re=
quest=C2=A0an API with the wrong password because a co-worker changed it. H=
ow would you know? Just my 2 cents.<br><br></div><span class=3D"gmail_signa=
ture_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div =
dir=3D"ltr">Iliya Miroslavov Iliev<div><a href=3D"mailto:i.miroslavov@gmail=
.com" target=3D"_blank"><font color=3D"#6aa84f">[email protected]</fon=
t></a><br></div></div></div></div>

--000000000000f18ce90658015394--