Re: [PHP-DEV] [RFC] Add CMS Support

This is only part of a thread. view whole thread
  110212
May 19, 2020 09:44 lear@lear.ch (Eliot Lear)
Dan, thanks.  Please see below.

On 18.05.20 13:49, Dan Ackroyd wrote:
> On Mon, 18 May 2020 at 10:55, Eliot Lear <lear@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
  110213
May 19, 2020 10:29 george.banyard@gmail.com ("G. P. B.")
On Tue, 19 May 2020 at 11:44, Eliot Lear <lear@lear.ch> wrote:

> Dan, thanks. Please see below. > > On 18.05.20 13:49, Dan Ackroyd wrote: > >> 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 >
I did start some work in this direction in: https://github.com/php/php-src/pull/5111 But I'm not super familiar with OpenSSL myself, any review/help would be appreciated (I do need to rebase it). Best regards George P. Banyard