On Thu, 30 Jun 2022 at 23:21, Levi Morrison via internals < internals@lists.php.net> wrote:
> On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron <pierr...@php.net> > wrote: > > One of the goal of this API is to tighten a problematic vulnerable area > > for applications where the URL parser library would believe one thing > > and libcurl another. This could and has sometimes led to security > > problems. > > Designing another API on top of what libcurl provides _could make the > problem worse_. My concern is rather the opposite: if it is not obvious *to someone writing PHP code* how the API should be used, there is a higher chance of them using it incorrectly, and introducing errors. A good example of this mindset is the password_* functions: they do not expose the options of underlying implementations, they present an easy-to-use *opinionated* set of behaviours, that solves a common use case for their audience. They allow users to "fall into the pit of success", because the easy thing is also the correct thing. However, to me at least, it's not entirely clear who the target audience for this API is, what tasks it should be making easy, and what correct usage looks like. Just providing a bunch of functions, in whatever form, doesn't provide security unless users can understand how to use them securely. Regards, -- Rowan Tommins [IMSoP]
