On Aug 2 2024, at 4:37 pm, Bilge <[email protected]> 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