Consider system_secret/user_secret acting as sink

[ohader]

https://psalm.dev/r/adf4fa4aea

<?php // --taint-analysis

/**
 * @param string $value
 * @param string $pepper
 * @return string
 * @psalm-taint-sink system_secret $value
 */
function signature(string $value, string $pepper = ''): string
{
    $key = 'secret_key_from_dotEnv';
    return hash_hmac('sha512', $value, $key . $pepper);
}

echo signature('static-command'); // expected usage, internal value
echo signature($_GET['command']); // possibility, to generate arbitrary valid signatures

It seems system_secret and user_secret currently can only be used as @psalm-taint-source - assigning @psalm-taint-sink system_secret seems to be ignored.

[psalm-github-bot[bot]]

I found these snippets:

https://psalm.dev/r/adf4fa4aea

```php

[ohader]

Alright... gave it some more thoughts...

• taint-type input is mapped to basically all specific types, except system_secret and user_secret
• @psalm-taint-sink system_secret $value did not work, since $_GET is just marked as input source (and expanded to specific types mentioned above)
• adding system_secret and user_secret to input would trigger lots of new code issue errors - in most cases false-positives → it's a bad idea

Conditional psalm-taint-source <taint-type | conditional>

(yay, more conditionals)

/**
 * @psalm-taint-source ($value is-source input ? 'system_secret' : null)
 */
function signature(string $value, string $pepper = ''): string {}

• in case $value is some input source
• mark function return statement as system_secret source
• $value is-source input condition is a new domain-specific scope,
• next to existing PHP scope like e.g. $value is true