Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130439
Precedence: list
MIME-Version: 1.0
References: <3f4f6959.eaf.19cf0276cd8.Coremail.lamentxu@163.com> <4bf704c.b746.19d20d429ac.Coremail.lamentxu@163.com>
In-Reply-To: <4bf704c.b746.19d20d429ac.Coremail.lamentxu@163.com>
Date: Tue, 24 Mar 2026 23:09:06 +0300
Message-ID: <CAPUh_1apjRxXZh3PoyrqFLUEodf3Zz9fyf5XZfV0YopORP5AoQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Remove \0 from default trim() character mask
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ef3405064dcab952"
From: go.al.ni@gmail.com

--000000000000ef3405064dcab952
Content-Type: text/plain; charset="UTF-8"

Hello.
Using trim() for binary data sounds like a mistake. There's nothing special
in whitespace or any other characters in binary data, so why use trim() for
it at all? If someone using trim for binary data, then this might be
deliberate choose. For example, trimming zero byte might be the sole cause.
That's why I disagree with "Secondly" RFC point.

Java's String.trim() treat characters with code points equals or less
than \u0020 as whitespace. So there's no "surprising case" at least for
java developers and that's why I disagree with "Thirdly" point.

However, I agree with "Firstly" point. But for semantic purists we
have mb_trim function.

Removing \0 from trim() makes code vulnerable to null byte injection attack
[1]. I have strong feeling that zero byte was added to trim() exactly by
this cause.

[1] https://owasp.org/www-community/attacks/Embedding_Null_Code

--000000000000ef3405064dcab952
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto">Hello.<div dir=3D"auto=
">Using trim() for binary data sounds like a mistake. There&#39;s nothing s=
pecial in whitespace or any other characters in binary data, so why use tri=
m() for it at all? If someone using trim for binary data, then this might b=
e deliberate choose. For example, trimming zero byte might be the sole caus=
e. That&#39;s why I disagree with &quot;Secondly&quot; RFC point.</div><div=
 dir=3D"auto"><br></div><div>Java&#39;s String.trim() treat characters with=
 code points equals or less than=C2=A0\u0020 as whitespace. So there&#39;s =
no &quot;surprising case&quot; at least for java developers and that&#39;s =
why I disagree with &quot;Thirdly&quot; point.</div><div><br></div><div>How=
ever, I agree with &quot;Firstly&quot; point. But for semantic purists we h=
ave=C2=A0mb_trim function.</div><div><br></div><div>Removing \0 from trim()=
 makes code vulnerable to null byte injection attack [1]. I have strong fee=
ling that zero byte was added to trim() exactly by this cause.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">[1]=C2=A0<a href=3D"https://owasp.or=
g/www-community/attacks/Embedding_Null_Code">https://owasp.org/www-communit=
y/attacks/Embedding_Null_Code</a><br></div></div></div>
</div>

--000000000000ef3405064dcab952--