Wouldn't a try/catch-approach be better than silencing the error?

Unfortunately, an exception is not thrown. A warning is raised, so even wrapping the code in a try catch block will still cause the warning to be outputted.

The warning I am talking about is something like: supplied key param cannot be coerced into a public key. This happens when the public or private key provided is not in the correct format.

In any case, we do not really care whether the public key is valid or not, only the fact that we can verify the signature is important.

See this example code for the warning being thrown even though we have wrapped it in a try-catch:

var_dump(openssl_verify('123456', '123456', 123456, 'sha256'));  //Causes a warning to be raised. returns false.

try {
   var_dump(openssl_verify('123456', '123456', 123456, 'sha256')); //Also causes a warning to be raised. returns false.
} catch (Exception $e) {
    var_dump($e); //never executed
}

var_dump(@openssl_verify('123456', '123456', 123456, 'sha256')); //No warning, returns false.

I was never a fan of using @ and use it very rarely in my applications, but I think in this case, it is appropriate as it may be beyond the scope of the library to set a set_error_handler().

I can't think of any library that has this issue, so I have nothing to compare it with. One solution could be:

function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, $errno, 0, $errfile, $errline);
}
set_error_handler("exception_error_handler");

try {
    var_dump(openssl_verify('123456', '123456', 123456, 'sha256'));
} catch (Exception $e) {
    var_dump($e); 
}

restore_error_handler();

That sounds like a possible solution as well :) However, perhaps it might be a bit overkill just to avoid the @, as a warning in this case would just return a false which is what we need.

Anyone else have any thoughts on this?

Please explain the situation in which these functions would throw an error

@bshaffer, when an invalid key is passed to openssl_verify, a warning will be thrown.

It expects keys in this format:

-----BEGIN PRIVATE KEY-----
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQC/yMgbkPnOnrXt
....
Fnh zeEVijg18pMvVScrBw==
-----END PRIVATE KEY-----

If for whatever reason, a corrupted version was stored by the storage driver or the key is tampered with, then a warning will be issued. In my previous comment, I passed 123456 to the function as the $key, which is invalid. This resulted in the openssl_verify function throwing a supplied key param cannot be coerced into a public key warning.

Is there a way to verify the input before calling the function? I agree we do not want to output php errors in this class, but squelching them is also not optimal

I just had a look at the openssl extension and it does not seem to provide any means to do so :(

Yes, it does seem squelching is the only way to handle this, unfortunately. I would suggest "decode" return false on failure however, rather than throw an Exception.

That's a good point :) I will get a pull out soon :)