On Aug 2 2024, at 4:37 pm, Bilge <bi...@scriptfusion.com> wrote:
> My only concern is there needs to be an alternative way to do this:
> intercepting internal calls. Sometimes, whether due to poor architecture or
> otherwise, we just need to be able to replace an internal function call. One
> example I can think of recently is where I had to replace `header()` with a
> void function in tests, just to stop some legacy code emitting headers before
> the main framework kicked in, then unable to emit its own response because
> HTTP headers had already been sent. In a perfect world it shouldn't be
> necessary, but sometimes it is, so I think for this proposal to be palpable
> there must still be a way to achieve this.
>
Just a tangent thought to the above, but I've always been a little concerned
with the idea that a malicious composer package could potentially do nasty
things because PHP looks at the local namespace first for functions. For
example, if a composer package focused on Laravel that defines malicious
versions of internal functions for common namespaces like App\Models ,
App\Http\Controllers , etc. it could do some nasty stuff -- and supply-chain
attacks aren't exactly uncommon. Even worse is Wordpress or any other PHP-based
software package that allows arbitrary plugins to be installed by non-technical
users who really would have no idea if the package was safe even if they were
looking at the code.
<?php
// something.php
namespace App\Models;
function password_hash(string $password, string|int|null $algo, array $options
= []): string
{
print("Hello");
return $password;
}
<?php
// my code
namespace App\Models;
include "something.php";
password_hash('foobar', PASSWORD_DEFAULT);
I don't recall why local namespace first won, but IMO it wasn't a great call
out the gate for that reason alone. Yes, you can always use \password_hash
instead of password_hash , but making the default insecure and slower is silly
IMO -- and not fixing it because of BC seems like the weaker argument here.
John
