Dan, thanks. Please see below.
On 18.05.20 13:49, Dan Ackroyd wrote:
> On Mon, 18 May 2020 at 10:55, Eliot Lear <l...@lear.ch> wrote:
>> there is an open question as
>> to whether it should be an RFC
> I don't think it should be.
>
> The questions and problems related to cryptography are far too
> detailed for a useful conversation to be had for anyone who doesn't
> understand them deeply.
>
> I certainly don't even understand all of the words in the RFC so won't
> comment on most of it.
>
> This is the type of thing that is better handled by trusting
> release-managers and subject matter experts.
Ok.
>
>> Returns TRUE on success and FALSE on failure.
> Have you considered using an exception for failures?
>
> First, having a cryptographic function fail is bad enough that it
> needs to break control flow, aka it would be easy to forget to check
> for false. If the $outfile already existed before the call, and the
> error condition wasn't checked, that could lead to Bad things.
>
> Second, I imagine there are multiple possible reasons why a crypto
> function could fail. If the error is just 'false', then there would be
> no way of figuring out what the problem is. More details could be
> provided in the message of an exception ("can't open file for
> writing", "signkey wrong format" etc) which would avoid a significant
> amount of frustration.
On your second point, the designers of OpenSSL and the earlier work on
the PHP interface agree with you, as do I. That is why there is indeed
an interface to return multiple errors that is already defined
(openssl_error_string) that can be called repeatedly. This is similar
to other OpenSSL interfaces.
On your first point, I might academically want to explore it, but then
we should do so for the entire openssl interface.
Eliot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
