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
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. Additional review is always welcome, and in particular I am
interested in any code that would exercise the flags argument, most
particularly CMS_STREAM. 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. I am going to ask the OpenSSL community about this
as well.
Eliot
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
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
TRUEon success andFALSEon 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
Dan, thanks. Please see below.
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
TRUEon success andFALSEon 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
Dan, thanks. Please see below.
Returns
TRUEon success andFALSEon 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
--
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
Hi everyone,
Following up on this work, I am pleased to say that the code is stable
and code complete. In discussions with this group and various
maintainers, it seems that people don't see the need for a VOTE on this
work. Therefore, unless there is an objection, I will work with the
maintainers to close off any dangling issues they might find, we'll
retire this RFC, and they can merge at their convenience.
This having been said... more code reviews are ALWAYS welcome.
Eliot