[RFC] Add CMS Support

  110152
May 13, 2020 19:54 lear@lear.ch (Eliot Lear)
Just to follow up on the earlier thread
(https://news-web.php.net/php.internals/110127), I've done my best to
create an RFC for the CMS support additions.  I would welcome any
comments or suggestions.  If folk don't want it to go through the whole
RFC process, that's fine by me.  Otherwise, it's there for your review
at https://wiki.php.net/rfc/add-cms-support.

Regards,

Eliot
  110203
May 18, 2020 09:55 lear@lear.ch (Eliot Lear)
--Lic9B2MKklKvxb2MvzgNkEsMbXHTtH5Hp
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Aannd as a reminder, this RFC is open, and there is an open question as
to whether it should be an RFC ;-)

Over the last week I did spot one additional problem in the code that I
fixed.=C2=A0 Additional review is always welcome, and in particular I am
interested in any code that would exercise the flags argument, most
particularly CMS_STREAM.=C2=A0 Because each of the arguments are files, I=
 am
wondering if I should reduce the coding complexity and just produce an
error on that flag.=C2=A0 I am going to ask the OpenSSL community about t=
his
as well.

Eliot

On 13.05.20 21:54, Eliot Lear wrote:
> Just to follow up on the earlier thread > (https://news-web.php.net/php.internals/110127), I've done my best to > create an RFC for the CMS support additions.=C2=A0 I would welcome any > comments or suggestions.=C2=A0 If folk don't want it to go through the = whole
> RFC process, that's fine by me.=C2=A0 Otherwise, it's there for your re= view
> at https://wiki.php.net/rfc/add-cms-support. > > Regards, > > Eliot >
--Lic9B2MKklKvxb2MvzgNkEsMbXHTtH5Hp--
  110204
May 18, 2020 11:49 Danack@basereality.com (Dan Ackroyd)
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.
> 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. cheers Dan Ack
  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